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? 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 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<mailto: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<https://code.launchpad.net/%7Esalvatore-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<mailto:so...@nicira.com>] Sent: 20 July 2011 17:55 To: Salvatore Orlando Cc: netstack@lists.launchpad.net<mailto: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<mailto: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<https://launchpad.net/%7Enetstack> Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~netstack<https://launchpad.net/%7Enetstack> More help : https://help.launchpad.net/ListHelp -- Somik Behera | Nicira Networks, Inc. | so...@nicira.com<mailto:sbeh...@nicira.com> | office: 650-390-6790<tel:650-390-6790> | cell: 512-577-6645<tel:512-577-6645> -- Somik Behera | Nicira Networks, Inc. | so...@nicira.com<mailto:sbeh...@nicira.com> | office: 650-390-6790<tel:650-390-6790> | cell: 512-577-6645<tel: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
