Ok, changed the name to refer to 1.0 API, and targeted for D-4 On Tue, Aug 2, 2011 at 2:20 PM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote:
> If we are planning to lock down our API v1.0 before Diablo-4, we can just > target the API blueprint to D-4.**** > > ** ** > > Salvatore**** > > ** ** > > *From:* Dan Wendlandt [mailto:d...@nicira.com] > *Sent:* 02 August 2011 22:15 > *To:* Salvatore Orlando > *Cc:* netstack@lists.launchpad.net > *Subject:* Re: [Netstack] Aligning API implementation with specification** > ** > > ** ** > > Great work Salvatore. I'd really like to have v1.0 of the API in Diablo-4, > so let's make sure we have a bug or blueprint targeted for that drop. **** > > ** ** > > Some thoughts inline below.**** > > ** ** > > Dan**** > > On Tue, Aug 2, 2011 at 9:39 AM, Salvatore Orlando < > salvatore.orla...@eu.citrix.com> wrote:**** > > Hi, **** > > **** > > In order to finalize a “v1.0” for the Quantum API we are currently > reviewing its specification and implementation. **** > > **** > > The reviewed API specification is much closer to the Openstack API. > However, there are a few “corner cases”: **** > > - Get Attached Resource operation: if no attachment is plugged > into a port should we raise an error?**** > > ** ** > > I would think that calling this might be done by a client to check whether > the interface has something attached or not, in which case returning a NULL > value would seem appropriate (this is easy to do in JSON, not sure about > XML). **** > > **** > > - Plugging an attachment in port whose state is ‘DOWN’. I think > this should be disallowed, and an exception raised. What’s your opinion?** > ** > > ** ** > > I think of the 'state' field as being similar to the 'admin status' of a > physical switch, in which case it would be valid to plug an interface into a > port that is admin down. Likewise, it is valid to put a port in admin down > even once it has something plugged into it (this can be simpler than > detaching and reattaching). **** > > **** > > **** > > The code currently diverges from the API. Realignment is being done in the > branch lp:~salvatore-orlando/quantum/quantum-api-aligment, linked to bug > #813433.**** > > Also two other branches contain code which will contribute to realign the > API impl with its spec. One removes the “PortCount” attribute, whereas the > other introduces the NetworkNameExists fault, which can be raised upon > network create/update operations.**** > > **** > > The next step will involve fixing accordingly unit tests and the client > library (which is going to hit trunk very soon). All of this will be done > within the api-alignment branch.**** > > **** > > The final step is to take a decision wrt synchronous vs asynchronous > behaviour of the API. **** > > I sent an email a couple of days ago on this topic. I thought a little bit > more about it, and I think it is reasonable that the actual behaviour > depends on the particular plugin implementation. It does not make a lot of > sense to force something which is inherently synchronous to be asynchronous. > **** > > However, a concept of “provisioning status” is probably need for Quantum > resources, and this status should be available through the API. **** > > Enumeration for resource statuses could be similar to the power_mapping > enumeration in Openstack API. **** > > In this way a synchronous plugin could return resource whose state is > typically “ACTIVE”, whereas an asynchronous plugin would return resources > whose state is usually “BUILD”. **** > > API users will be aware of this, as the status of an operation will be > clearly documented in the API specification. On the other hand, the API will > refuse to execute operations on resource whose provisioning state is not > “ACTIVE”.**** > > ** ** > > I like the idea of an enumerated status here. I want to think more about > whether the API should reject calls during a "build" phase. I was more > thinking that the API user could make whatever requests they want at any > point, but a status might indicate that the system has not yet been able to > actually provision the corresponding network behavior. **** > > **** > > I would be more than happy to discuss these item during today’s meeting. My > aim is to lock down the specification as soon as possible (end of the > week?), and then merge the alignment branch shortly after.**** > > ** ** > > Great. Given how long our meetings have been running, longer debates > should probably live on the mailing list, but I already have a spot on the > agenda to discuss the API spec. **** > > ** ** > > ** ** > > **** > > **** > > Regards, **** > > Salvatore**** > > **** > > > -- > 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
