I like the model 2 as well. I'm not an API expert, but for any "Cloud API" following asynchronous model is a basic design tenet and IMHO must be supported.
On the persistence or DB side, on 802.1qbh plugin, we saw the need for a persistence store. We are adding that function with ORM/mysql. Rohit A from our team can share the code in next few days. If we all find it relevant and helpful to expand it as "Quantum DB" then it's a good place to start. Also we need to go thru "recovery and state restore" model for Quantum. How Quantum keeps the "state of the resources" if its restarted or worse crashes and comes back? I'm not clear. Ram -----Original Message----- From: netstack-bounces+radurair=cisco....@lists.launchpad.net [mailto:netstack-bounces+radurair=cisco....@lists.launchpad.net] On Behalf Of Troy Toman Sent: Wednesday, July 27, 2011 9:15 AM To: Salvatore Orlando Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] Quantum API question - port creation 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 -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
