Thanks Salvatore! On Fri, Aug 5, 2011 at 2:34 PM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote:
> Hi Somik, **** > > ** ** > > Please see my replies inline.**** > > ** ** > > *From:* Somik Behera [mailto:so...@nicira.com] > *Sent:* 05 August 2011 21:41 > > *To:* Salvatore Orlando > *Cc:* netstack@lists.launchpad.net > *Subject:* Re: [Netstack] Aligning the API code with the specification**** > > ** ** > > 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.**** > > I understand your concern. Do you reckon the resource status concept should > still be part of API v1.0, or should we introduce it at a later stage, and > therefore target post-Diablo release? > I suggest we split this for now, if we have agreement and branch ready we can do it in D4, but post-diablo shouldn't be a big deal either. After all the post-diablo in OpenStack time scale is pretty soon too. > > > 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.**** > > Will do. **** > > > > 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 > > **** > > Thanks for spotting this. I’ll fix the spec wiki page.**** > > > 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 will add the detail action for the port as well. To stress consistency, > we might probably add also a /networks/{net-id}/ports/detail action as we > already have /networks/{net-id}/detail. > I did notice that we have details for /networks/{net-id}/detail, I just wanted to add the same to ports. So we are good then > **** > > > 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**** > -- 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
