Hi Ram, Inline. Thanks,
Dan On Wed, Jul 27, 2011 at 12:13 PM, Ram Durairaj (radurair) < radur...@cisco.com> wrote: > Hi Dan:**** > > > Responses embedded.**** > > ** ** > > *From:* Dan Wendlandt [mailto:d...@nicira.com] > *Sent:* Wednesday, July 27, 2011 10:04 AM > *To:* Ram Durairaj (radurair) > *Cc:* Troy Toman; Salvatore Orlando; netstack@lists.launchpad.net > > *Subject:* Re: [Netstack] Quantum API question - port creation**** > > ** ** > > ** ** > > 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? **** > > *[Ram Durairaj (radurair)] I don’t think we “replaced” the quantum/db > model/code. We extended it to support 802.1qbh and extensions* > > *Rohit will put his code and the related doc in next few days for all of > to take a look* > Ok, great. So far the general thinking has been that models that are specific to a plugin will go in the plugin directory and models that are more general will go in quantum/db. There's obviously a lot of grey area here though, for example, if you have a model for an extension that you would like other people to adopts as a standard, it could make sense to put it in quantum/db . For now we don't really have a hard and fast rule here. > **** > > **** > > > 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? *[Ram Durairaj (radurair)] * Yes. With the “pass thru” model > everything is the responsibility of the plugin. With the discussion below > and my general understanding of the model 2 proposed, do you think we may > need to keep a persistence at the Quantum “API layer” > Personally, I am not in favor of a persistence model in the API layer, with a possible exception that Salvatore and I chatted about related to API auth data if it turns out that we can't leverage keystone as we'd like. So far, we've been treating the sqlalchemy models in quantum/db as helpers that can make it easier to build a plugin if you want to use them, while the plugin API is the definitive abstraction. This is nice in that it is simple to build a plugin that uses sqlalchemy, while not limiting people who want to build a pass-thru plugin where data is actually stored in a different platform. > **** > > ** ** > > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~**** > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
