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. 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 -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
