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....@lists.launchpad.net >> [mailto:netstack- >> bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net] On Behalf Of >> Troy Toman >> Sent: 25 July 2011 18:57 >> To: 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 >> 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 Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
