Hi Dan, Let's finalize a decision on the target API version in today's meeting. As we're quite close to a major deadline, I'd focus more on delivering what's been previously agreed on rather than on discussing enhancements, even if rather important.
In order to get to the bottom of our differences, let me ask you a simple question: We are writing a client application for quantum. The client at a certain point creates a resource, say a network. The client then will create a bunch of port on this network. Will it execute the "create port" operation immediately after creating the network, or will it wait for the network to be "operationally ready" and then submit the "port create" operations? I also have a few comments inline. Cheers, Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 09 August 2011 01:21 To: Salvatore Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Quantum API resource status proposal Hi Salvatore, I think we're getting close :) As you mentioned in the bug, I agree that the "status" attributes are not critical for the v1.0 API, so delaying them until 1.1 so we can make sure we're on the same page seems like a good decision. Some comments inline, Dan On Mon, Aug 8, 2011 at 3:29 PM, Salvatore Orlando <salvatore.orla...@eu.citrix.com<mailto:salvatore.orla...@eu.citrix.com>> wrote: Hi Dan, Thanks for your comments. I have a few replies inline. I hope in tomorrow's meeting we can at least finalize a decision on whether we want or not some form of "state" concept in API 1.0. Salvatore From: Dan Wendlandt [mailto:d...@nicira.com<mailto:d...@nicira.com>] Sent: 08 August 2011 20:00 To: Salvatore Orlando Cc: netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> Subject: Re: [Netstack] Quantum API resource status proposal Thanks for the explanation Salvatore, very helpful to understand where you are coming from. I think we're approaching this from slightly different angles, but aren't too far off. My thinking was that most (all?) plugins will operate in a way that they store the data resulting from a web service call before returning (e.g., receive the call, update the database, return). The corresponding "wiring" work to configure switch could then likely happen asynchronously. Agreed. This model gives you the nice properties that once I've done a create, I can always use the identifiers returned in the create response in subsequent calls without having to do any polling. I wonder if it is possible that we instead just say that the API should not return an identifier from a create call until it is ready to accept subsequent calls using the returned identifier (note: this says nothing about whether that functionality is "wired", which may happen asynchronously, just whether the existence of an API object has been stored). It seems like a plugin should be able to store and return the data with minimal effort, but perhaps I'm missing a scenario where this wouldn't be the case. It looks like you are separating "API objects", which are stored by the plugin upon API calls, from "wired objects", which are the actual bits configured for making virtual networks work. I totally agree on this separation. Yes, that is correct. Let's use that terminology to stay consistent. I think of there being a set of logical "API objects", which can be modified by the client at any point. The plugin in then responsible for mapping the configuration described in the "API objects" to actual "wired objects", which it may do asynchronously. The client should always be able to check on whether the plugin has completed the task of mapping the "API object" to the "wired object" (in my previous email I think we were referring to this as "link status" or "operational status"). Right. So we definitely agree that we need a concept of "OPERATIONAL STATUS" which is attached to the "API OBJECT". Client applications always deal with "API OBJECTS", and are not even aware of "WIRED OBJECTS". The notion of operational status allows client applications to understand whether the "WIRED OBJECTS(s)" mapped to a given API OBJECT are in status that can be operated on. However, it also seems to me that in your view the API should be happy to operate as long as an "API object" exists regardless of whether the corresponding "wired object" has been created or not. For instance let's imagine we want to do the following operations: 1. Create port on network 2. Plug interface The client first executes the first operation. The plugin creates the API object, returns it to the caller; "wired" objects creation could still be in progress, but the API object is there; the client is therefore able to run the second operation. I think this would simplify clients, This would indeed simplify a lot the client, because the concept of state provisioning would be totally superfluous. If the client has an API object identifier, it can operate on it; simple as that. However, we also have to ask ourselves whether this model is simple or simplistic. Can we always assume that a client can operate without knowing anything about whether the "wired objects" have been created or not? I definitely didn't mean to imply that. Sorry about that. I must have misunderstood your previous email. I agree that the client should be able to know whether the underlying "wired objects" have been created (e.g., via an exposed "operational status" as described above), I just don't think that the status of the "wired object" should affect whether you can operation on the "API object". Let's imagine the provisioning process for operation #1 takes a long time. The API returns the port identifier to the client, which then invokes the operation for plugging the interface. At this stage the "wired" port object is not yet ready, but the API object is there in the DB. >From what I've seen in this thread it seems we are considering the following >options: 1. The API object has a notion of "state", which reflect the state of the underlying wired object. If the wired object (port in this case), has not yet been created, the state for the API object will be "BUILDING", "PROVISIONING", "INPROGRESS", or something like that. This would be what I was proposing to do with the "resource status" proposal 2. The API object is updated regardless of the state of the underlying "wired" object(s). The actual success/completion of the "Plug" operation will be reported by the "Logical status" associated with the port; for instance while the wired objects are being created, the status will be "DOWN". I think what I was shooting for was some kind of mix of #1 and #2: "API objects" can be updated regardless of the underlying "wired objects", but a "resource status" always tells you if there is a difference between the connectivity described by the "API object" and the reality of packet forwarding done in the "wired object". I like this dualism. The model described by the API objects is an ideal world, more like a diagram on the whiteboard, where everything works magically. Wired objects instead represent the "ugly" real world, where things take time to complete, and failures tend to occur. Resource status is the thing that warns of a delta between the API object model and the wired object model. This reminds me a bit configuration management systems :) Is it possible that the "resource status" described in your #1 is similar to the "operational status" I described above? I tend to see the "resource status" as being either "up" or "down", with down having a variety of explanations why things are "down" if (e.g., building, interface-id-not-found, internal-error, resources-not-available, etc.) Yes, it is. We already clarified this in a previous post on this thread. And this is also not very dissimilar from the concept of "server status" in nova. Atlas-LB too has a very similar concept for LB server provisioning. This sounds pretty similar to what you're talking about with #1, so I'm hoping we're thinking close to the same thing. :) Hopefully yes! 3. Don't care about the state of the "wired" object. If the API object is there, operate on it; the plugin will take care of the rest and the client is supposed to be unaware of what the plugin does behind the covers. Definitely agree that this is not the way to go :) Good. We can definitely discard this option (which is what the current API does :) ) I'm in favour of approach #1, and I see it as a generalization of approach #2, as it doesn't seem to me that the concept of logical status for a port clashes with the concept of provisioning state. I'm not in favour of approach #3, as I reckon the client wants to (and deserves to :)) know whether the actual "wired object" have been created and are working as expected. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com<http://www.nicira.com> | www.openvswitch.org<http://www.openvswitch.org> Sr. Product Manager cell: 650-906-2650 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
