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. 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. 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. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
