I agree with Troy that we should focus on consistency. Ideally API users are not aware of which plugin the Quantum service is running; indeed the might totally ignore the fact that Quantum is being powered by a plugin. Therefore the asynchronous/synchronous behaviour of an operation should be considered from the point of view of the API user, which will reasonably expect the same behaviour regardless of the particular plugin loaded.
Even if we are striving to comply as much as possible with nova's Openstack API IMHO this does not imply we should slavishly imitate it. For instance, if I'm not wrong, Glance API is synchronous. As concerns Quantum, I think the synchronous/asynchronous choice is not very easy: * From the API side, there are operations such as "create port" or "plug interface" which we might expect to be invoked at least with same frequency as "create server" in nova; this would probably call for an asynchronous model for scalability reasons; * From the plugin side, operations such as "create network" can have a very different behaviour according to the particular plugin: for instance a synchronous behaviour appears to be good enough for our OVS plugin, and it will be good enough for a plugin implementing the VLAN manager porting; on the other hand a 802.1qbh plugin will probably have a more complex provisioning process (I guess), as it will involve configuring virtual switches, IV modules, and physical switches. It is my opinion that the asynchronous approach, being more generic, might be the best solution for Quantum. However, this might require a few more coding work, as: 1. We would need to implement the provisioning process mentioned in this thread; 2. We would need some form of message-passing backend (I'd borrow it from nova, if that is the case!); 3. And finally, we would need to adapt the plugin interface to support the required changes. Summarizing this will leave us with a few choices: * Keep things easy for the first release: the API will define the behaviour of the operation (sync vs async), and then it is responsibility of the plugin to provide this behaviour. Behaviour will possibly be enforced in the API in the next release. A consequence of this would be that this will imply a change in the plugin interface thus breaking bw compatibility; * Enforce the behaviour in the API immediately, possibly choosing an asynchronous model. Regards, Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 27 July 2011 18:42 To: Troy Toman Cc: Salvatore Orlando; netstack@lists.launchpad.net Subject: Re: [Netstack] Quantum API question - port creation On Wed, Jul 27, 2011 at 10:23 AM, Troy Toman <troy.to...@rackspace.com<mailto:troy.to...@rackspace.com>> wrote: On Jul 27, 2011, at 12:17 PM, Dan Wendlandt wrote: To clarify, I think the question is whether the API layer should enforce that the implementation is asynchronous, or leave it up to the plugin. In general my preference is to leave things up to the plugin, but this has the possible downside that people might write clients that assume synchronous behavior if they start using a plugin that just happens to be synchronous, then switch. The problem with that its that what you can expect to get back could possibly change. If you are happy with only getting the ID back regardless of how it is implemented. Then I suppose the decision could be left to the plug in. While it is more flexible, I think it makes it harder to predictably design a service around it know that behavior will vary. I would lean on the side of consistency here. Yeah, that is the concern I was trying to express above as well. I don't really feel strongly on this one, so if we want to "enforce" this in the API, i think it is reasonable. Also, Troy: in the nova API, is there a guarantee that all subsequent GET requests will return all fields (i.e., only the POST is allowed to be async?). Thanks, Not sure what you mean by guarantee. The attributes returned by the GET call are spec'd to be consistent. But, if you did a GET before the provisioning was complete, you may not get the final values for all fields. For instance, if a server is in BUILD status when you do a GET, it might not have an assigned IP returned if the IP assignment has not completed. You would just have nothing for that field. I meant "guarantee" in the sense used in the spec: "Note that when creating a server only the server ID, its links, and the admin password are guaranteed to be returned in the request.". Is there equivalent wording for GETs? From your response, it sounds like the answer is yes and if we go down this route for Quantum, we should probably have equivalent wording in our spec as well. If we were to go this route, we might need to consider having a status field for ports that includes a BUILD or PROVISIONING status that reflects an incomplete provisioning process. agreed. Dan On Wed, Jul 27, 2011 at 9:57 AM, Dan Wendlandt <d...@nicira.com<mailto:d...@nicira.com>> wrote: It sounds like the nova API that troy referenced does not REQUIRE the call to be asynchronous, rather it ALLOWS the call to be asynchronous by saying that only a subset of the attributes must be returned in the POST: "Note that when creating a server only the server ID, its links, and the admin password are guaranteed to be returned in the request. Additional attributes may be retrieved by performing subsequent GETs on the server." So I would say there is nothing wrong with a plugin implementation that is synchronous, its more that you have the option to choose to be synchronous or asynchronous and still be "legal" according to the API spec. Dan On Wed, Jul 27, 2011 at 9:14 AM, Troy Toman <troy.to...@rackspace.com<mailto:troy.to...@rackspace.com>> wrote: On Jul 27, 2011, at 10:00 AM, Salvatore Orlando wrote: > Hi Troy, > > This is a very good point in light of the work I'm doing for making sure the > API specification is consistent with its implementation. > > Consistency with Openstack API is one of the reasons for which the > specification states that port creation should happen asynchronously (as well > as other operations on ports and networks). > However, the API implementation is currently unable to do so because it acts > merely as a proxy for the plugin: it parses input parameters from the > request, feeds them to the plugin, gets the return value from the plugin, and > marshals it into the response. > > It is my opinion that there are several ways in which these operations can be > made asynchronous: > 1) Let the plugin provide the asynchronous behaviour - i.e.: it creates the > port, return its identifier and then complete all related operations in the > background; > 2) Let Quantum create an abstract port object, asynchronously invoke the > plugin to perform the actual operation, and return the identifier of the > previously created port object; > 3) Change CREATE, PUT, and DELETE operations in a way that they always return > only a 202/204 Status code and a transaction ID. Clients can then check > operation completion status and possibly retrieving the object > created/updated by querying the transaction ID. > > Ideally I would follow approach #2. I think approach #3 is unnecessarily > complex, whereas approach #1 would just delegate to the plugin a requirement > that the API is supposed to satisfy. > > As regards approach #2, the only problem I see is that it requires Quantum to > be able to perform CRUD operation on network and port objects. We already > agreed we will not have a Quantum database, at least not in this first > release; although I was personally supportive of the idea of a "Quantum DB", > there are good arguments for not having it. I prefer approach #2 as well. Would it be possible to have Quantum create and ID, return it in the response and then pass it to the plugin with part of the contract requiring the plugin use that ID? So, the ID is tracked in the plugin but created in Quantum? > > Of course, one alternative is to remove the a-synchronicity requirement from > the API spec; not sure this is a good thing, though. > Summarizing, I think that even if this is probably not a high priority task, > it is definitely something that we want to address before the Diablo release. > > Any comment? > > Regards, > Salvatore > > >> -----Original Message----- >> From: netstack- >> bounces+salvatore.orlando=eu.citrix.com<http://eu.citrix.com/>@lists.launchpad.net<http://lists.launchpad.net/> >> [mailto:netstack-<mailto:netstack-> >> bounces+salvatore.orlando=eu.citrix.com<http://eu.citrix.com/>@lists.launchpad.net<http://lists.launchpad.net/>] >> On Behalf Of >> Troy Toman >> Sent: 25 July 2011 18:57 >> To: netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> >> Subject: [Netstack] Quantum API question - port creation >> >> In reviewing the spec for creating ports, it is stated that it should >> asychronously create a port. But, it reviewing the implementation and even >> in the discussion of what data is returned, this does not seem to be an async >> operation. I would prefer to see this mirror the Nova API spec where creates >> just return an ID. From the API 1.1 spec: >> >> "Note that when creating a server only the server ID, its links, and the >> admin >> password are guaranteed to be returned in the request. Additional attributes >> may be retrieved by performing subsequent GETs on the server." >> >> Thoughts? >> >> Troy >> This email may include confidential information. If you received it in error, >> please delete it. >> >> >> -- >> Mailing list: https://launchpad.net/~netstack >> Post to : >> netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> >> Unsubscribe : https://launchpad.net/~netstack >> More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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<tel:650-906-2650> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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<tel:650-906-2650> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ This email may include confidential information. If you received it in error, please delete it. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
