On Wed, Jul 27, 2011 at 9:48 AM, Ram Durairaj (radurair) <radur...@cisco.com > wrote:
> 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. > Hi Ram, could you expand on this? How does this compare to the sqlalchemy code in quantum/db/models.py? > > 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. > Right now the model is that the state is stored and managed by the plugin itself, to enable a pass-through model where the persistent data store may be somewhere else. The plugin should obviously use a datastore that can persist across failures + crashes. Or are you looking for something more general? Thanks, Dan > > 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 > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | 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
