Hi Salvatore, Thanks for your continued contribution to getting our API house in order! I am hoping after this we can figure a way to "lock" the wiki so that we deliver this API and then try to work on the next rev.
I have two high-level points regarding the current spec as it stands today and few other minor issues, high level points: 1) We should separate the 'state for every resource' discussion from this blueprint as this blueprint was originally only for previously agreed upon stuff, which didn't include async. API enforcement at API nor states for all resources. With that said, I would say that I am in favor of introducing resource states and we need to discuss and finalize what states are valid but I dont feel it should be part of this blueprint, we can create another API enhancements blueprint or bug for addressing states. 2) OpenStack API guidelines - http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/os-compute-devguide-cactus.pdf, species that the server should accept 2 ways of specifying the wire format: * ".json" or ".xml" suffix to URI * setting the content-type header attribute. Traditionally, I have seen content-type header is the place where we embed this information. Therefore, we should clarify that we support setting the wire-format at both places in the API blueprint. Minor issues: 1) Show network (details) call's example XML/ JSON/HTTP request seems incorrect. It says: GET /tenants/XYZ/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3.xml It should be: GET /tenants/XYZ/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/details.xml 2) To be consistent with above /details API, we should have a GET .../ports/<port-id>/details.xml API too In case of port details we will return the attachment-id for now and in the future there can be more port details. I think we are very close to getting this thing done! I think its time we start thinking of interesting applications/demos of our API for the Boston design summit! Thanks, Somik On Thu, Jul 21, 2011 at 7:45 AM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote: > Hi, **** > > ** ** > > I have performed a review of the API specification in order to make it as > compliant as possible with the convention of the Openstack API > specification. **** > > Moreover, for each operation I have added samples of request and response > objects, in order to give a clear picture of what should be supplied in > request bodies and what to expect in response bodies. **** > > ** ** > > The API specification is at: http://wiki.openstack.org/QuantumAPISpec; you > can compare the changes wrt the previous version of the specification, which > can be found at the following address: > http://wiki.openstack.org/QuantumAPISpec?action=recall&rev=28**** > > ** ** > > Your feedback is, as usual, more than welcome!**** > > ** ** > > The following branch has been set up to align the API specification with > the implementation: > https://code.launchpad.net/~salvatore-orlando/quantum/quantum-api-alignment > **** > > The branch has been linked to the bug report filed yesterday: > https://bugs.launchpad.net/quantum/+bug/813433 **** > > ** ** > > I agree with Somik that we can start merging the unit tests branch, as long > as no other concern emerges from the review currently in progress. **** > > ** ** > > Salvatore**** > > ** ** > > *From:* Somik Behera [mailto:so...@nicira.com] > *Sent:* 20 July 2011 17:55 > *To:* Salvatore Orlando > *Cc:* netstack@lists.launchpad.net > *Subject:* Re: [Netstack] Aligning the API code with the specification**** > > ** ** > > Hi Salvatore, > > Your current line of thinking makes sense to me. I am doing a review of the > branch, and will send out a response soon. We should try to get the unit > tests merged soon and then create high priority "test stopper" bugs around > API spec divergence and try to fix them as soon as possible. This way we can > unblock all merges and proceed towards getting our tests fixed as first > order of business. > > Thanks, > Somik**** > > On Wed, Jul 20, 2011 at 4:15 AM, Salvatore Orlando < > salvatore.orla...@eu.citrix.com> wrote:**** > > Hi all, **** > > **** > > There are currently several parts of the API implementation that are not > aligned with the specification.**** > > This happened as the specification was updated while the API was being > implemented, and therefore the API code now does not reflect the > specification.**** > > **** > > These issues came out while developing code for API unit tests, and Somik > has done a great job in pointing them out here:**** > > > https://code.launchpad.net/~netstack/quantum/quantum-unit-tests/+merge/68308<https://code.launchpad.net/%7Enetstack/quantum/quantum-unit-tests/+merge/68308> > **** > > **** > > It is my opinion that the current API specification should be reviewed in > order to:**** > > · Ensure it complies as much as possible with standards adopted in > the Openstack API;**** > > · Providing full specification for format of request/response > objects, both in JSON and XML;**** > > · Make sure all status codes are meaningful, and not overlapping > with HTTP specification.**** > > **** > > We will then need to update unit tests and API code in order to reflect > these changes. **** > > I have created a bug report to track progress on this issue on Launchpad: > https://bugs.launchpad.net/quantum/+bug/813433**** > > **** > > I shall start work on the API specification today. I will post on this > thread when the work is complete. In the meanwhile we should decide whether > to postpone merging branches into Quantum trunk until the API specification > review is complete. My personal opinion is that we should proceed to merge > unit tests branch and unblock the current merge queue, and give High > priority to the above mentioned bug in order to make sure relevant > adjustments, both in code and specification are agreed and applied as soon > as possible.**** > > **** > > Any thoughts?**** > > **** > > Cheers, **** > > 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**** > > > > > -- > Somik Behera | Nicira Networks, Inc. | so...@nicira.com<sbeh...@nicira.com> | > office: 650-390-6790 | cell: 512-577-6645**** > -- Somik Behera | Nicira Networks, Inc. | so...@nicira.com <sbeh...@nicira.com> | office: 650-390-6790 | cell: 512-577-6645
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
