Generic mechanism for switch commands

[henn]

It sounds like now might be the time to implement the more general Switch-command option/closure thing we discussed in #784 and #508. This is due to to #755.

While designing this, I'd suggest to keep in mind that we would like to use this as a mechanism for keeping a compromise of the front-end HIL REST API server from being able to run arbitrary commands against or get the credentials for the switch.

[zenhack]

My original thought was to basically do JSON rpc:

http://www.jsonrpc.org/specification

The 10,000 foot view is:

{
    "jsonrpc": "2.0",
    "method": "modify_port",
    "params": {
        "channel": "vlan/native",
        "new_network": null,
        "port": "gi1/0/4"
    },
    "id": 1
}

There's a response object that looks pretty similar, but has either "result" or "error" instead of "params". "id" is used to correlate requests and responses. Leaving off "id" indicates not wanting the result.

One thing that makes this a little awkward in the current context is that we're doing things queued rather than synchronously (which was the whole point in the daemon in the first place).

Thoughts? We can use this space to brainstorm. We should pin down a specific set of requirements. This came out of the observation that we seemed to be drifting towards a generic mechanism for making calls to the network daemon, and wanted to do so in a principled fashion, but we haven't really dug too much into discussions of what it should look like.

[naved001]

We should pin down a specific set of requirements.

To answer this question, we should figure out things we can't do with the current implementation (or difficult to do)

1. We want to be able to do more things with the switch at this point (instead of just doing modify-port and revert-port).
2. ability to do switch ops based on ports (not necessarily nics).
3. if switch raises an error, we can't really handle it.

One thing that makes this a little awkward in the current context is that we're doing things queued rather than synchronously (which was the whole point in the daemon in the first place).

if the networking daemon is running on a single thread wouldn't the requests be automatically queued?

[naved001]

I am inclined to simply add a few more columns to the networking action table. Those columns can hold a UUID and the status (success, error, in progress). The APIs that perform network action can return the UUID for it. And then there'll be a new API to query the status of the networking operation using the UUID that was returned. This seems pretty simple to implement. This was suggested by @knikolla

To answer my questions I raised above.

1. We can add more valid switch operations in addition to modify-port and revert-port.
2. With this, we are still stuck with doing operations based on nic, and not port. But now that I think of it, there will be (or at least, shouldn't be) no free ports registered in HIL. Every port must be connected to a nic, otherwise it's useless for HIL.
3. If the status turns out to be error, then we don't make the database change. The user would see that their node had no change in networks, and they can confirm that using the new API to see that their last call errored out.

[zenhack]

Quoting Naved Ansari (2017-12-13 10:53:31)

I am inclined to simply add a few more columns to the networking action table. Those columns can hold a UUID and the status (success, error, in progress). The APIs that perform network action can return the UUID for it. And then there'll be a new API to query the status of the networking operation using the UUID that was returned. This seems pretty simple to implement. This was suggested by [1]@knikolla

This is roughly what I'd had in mind, and I think it's a good idea.

Much of the discussion here is about moving towards de-coupling the network daemon from the api server, but I don't think this proposal will set us back on that at all.

2. With this, we are still stuck with doing operations based on nic,
   and not port. But now that I think of it, there will be (or at
   least, shouldn't be) no free ports registered in HIL. Every port
   must be connected to a nic, otherwise it's useless for HIL.

The motivation for the switch was for port_revert, which an administrator may want to call during setup. They can probably do this after attaching a NIC, but it would be a natural thing to want to do it right away. I don't feel terribly strongly about this though.