Re: [Netstack] [Merge] lp:~netstack/quantum/quantum-unit-tests into lp:quantum
Review: Needs Information netstack-core Great work on this changelist Salvatore! This was much needed. I do have a few questions, while not directly related to this branch, they did bring up questions in my mind around our official API Spec? I felt the Error codes weren't correct and looking at the API Spec wiki, it seems the wiki has another completely separate list of error codes. Which is the API spec that you are working off? Just so that we can all be on the same page and update the spec. from a single source. I think besides that we are very close to checking in. I just wouldn't want our unit test to giving us "green" light even when they are diverging from our Spec., thats why I had these questions. 1) The WSGI logging, at debug level can be helpful. 2) What's the motivation for introducing options in the ABC? Currently all plugin specific config is inside the plugin. Why introduce this for FakePlugin? 3) def _test_show_network_not_found(self, format): -- HTTP code for Not Found is 404, why are we asserting 420? 4)def _test_rename_network(self, format): -- The final assert violates the data format of specified in quantum_plugin_base. The 'id' should be 'net-id' and name should be 'net-name' 5) Also as for 202, shouldn't we use 200:OK ( Request Completed) rather than 202: Accepted ( accepted for processing without guarantees of completion.) 6) def _test_delete_network_in_use(self, format): -- I see 421 here, no idea what does that represent. 7) def _test_show_port_portnotfound(self, format): -- ERROR code 430? 8) _test_delete_port_in_use(self, format): - We have 432 here, can we use well defined error codes from here - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 9) I also noticed that the error are not consistent with what we have in the API Spec - http://wiki.openstack.org/QuantumAPISpec but we can tackle those as bugs but our unit tests should reflect them as bugs. -- https://code.launchpad.net/~netstack/quantum/quantum-unit-tests/+merge/68308 Your team Netstack is subscribed to branch lp:~netstack/quantum/quantum-unit-tests. -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
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 | 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
Re: [Netstack] [Merge] lp:~netstack/quantum/quantum-unit-tests into lp:quantum
e the spec was reviewed after > the first draft of the API was implemented. We definitely need to > synchronize spec and code. This is one of the thing I noticed while > developin the unit tests. My opinion is that any discussion on the API spec > will involve discussion, and therefore time. > > I was therefore aiming at merging the unit tests, which are semantically > correct, and then start a discussion around fixing the API, as I mentioned > at the end of today's meeting. > > What's your opinion? Should we first sync code and spec and then merge unit > tests. Alternatively we could sync the unit tests alone with the API spec, > and merge them. As you might expect most of the test will fail. Then we can > push bug fixes to align the API code with the spec. > -- > > https://code.launchpad.net/~netstack/quantum/quantum-unit-tests/+merge/68308<https://code.launchpad.net/%7Enetstack/quantum/quantum-unit-tests/+merge/68308> > You are reviewing the proposed merge of > lp:~netstack/quantum/quantum-unit-tests into lp:quantum. > I vote that we file bugs for things we know coming out of this CL and then we can merge the this branch, and start working on high priority API bugs. -- Somik Behera | Nicira Networks, Inc. | so...@nicira.com | office: 650-390-6790 | cell: 512-577-6645 https://code.launchpad.net/~netstack/quantum/quantum-unit-tests/+merge/68308 Your team Netstack is subscribed to branch lp:~netstack/quantum/quantum-unit-tests. -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] [Merge] lp:~netstack/quantum/quantum-unit-tests into lp:quantum
Review: Approve netstack-core Great work Salvatore! We are getting there. I am approving this for merge to trunk as this branch is definitely a step in the right direction. -- https://code.launchpad.net/~netstack/quantum/quantum-unit-tests/+merge/68308 Your team Netstack is subscribed to branch lp:~netstack/quantum/quantum-unit-tests. -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
[Netstack] [Merge] lp:~netstack/quantum/quantum-unit-tests into lp:quantum
The proposal to merge lp:~netstack/quantum/quantum-unit-tests into lp:quantum has been updated. Status: Needs review => Approved For more details, see: https://code.launchpad.net/~netstack/quantum/quantum-unit-tests/+merge/68308 -- https://code.launchpad.net/~netstack/quantum/quantum-unit-tests/+merge/68308 Your team Netstack is subscribed to branch lp:~netstack/quantum/quantum-unit-tests. -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] reviews, merges, and next steps
This is a long awaited branch! It had slipped me, I'll review it soon. Thanks, Somik On Fri, Jul 29, 2011 at 8:45 AM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote: > Hi, > > ** ** > > I would like to add that the branch that fixes most of the failing tests > is: > https://code.launchpad.net/~salvatore-orlando/quantum/quantum-api/+merge/65979 > > > This branch has been waiting for a review for a week now. > > The “needs fixing” vote that you see on the merge proposal is related to a > previous revision of the branch. Comments in that review have already been > addressed. > > ** ** > > Thanks, > > Salvatore > > ** ** > > *From:* netstack-bounces+salvatore.orlando=eu.citrix.com@ > lists.launchpad.net [mailto:netstack-bounces+salvatore.orlando= > eu.citrix@lists.launchpad.net] *On Behalf Of *Dan Wendlandt > *Sent:* 29 July 2011 15:43 > *To:* Santhosh Kumar M > *Cc:* netstack@lists.launchpad.net > *Subject:* Re: [Netstack] reviews, merges, and next steps > > ** ** > > Thanks for pointing that out Santhosh. To avoid confusion, I updated the > status of the old merge request from "work in progress" to "rejected" to > indicate that it is no longer expected to be merged (this should keep the > history around, as I did not delete the merge request). The new merge > request is still active. Thanks, > > ** ** > > Dan > > ** ** > > On Thu, Jul 28, 2011 at 9:42 PM, Santhosh Kumar M < > sant...@thoughtworks.com> wrote: > > Hi Dan, > > ** ** > > There is one correction in the api-extensions merge prop. > > The latest merge prop is > https://code.launchpad.net/~raxnetworking/quantum/api_extensions. This > branch supports dynamically enabling/disabling extensions for the plugin.* > *** > > ** ** > > The link you have mentioned is the old branch, we left that prop to keep a > log of the discussions happened. > > ** ** > > On Fri, Jul 29, 2011 at 8:59 AM, Dan Wendlandt wrote: > > Ok, so we're trying to clear a bunch of small bugs out the the pipeline, > should be easy reviews: > > ** ** > > - > https://code.launchpad.net/~tylesmit/quantum/quantum-bug-814517/+merge/69477 > > > - https://code.launchpad.net/~danwent/quantum/bug814012/+merge/69505 > > - https://code.launchpad.net/~danwent/quantum/bug817813/+merge/69737 > > ** ** > > I believe we're one more bug away from having clean unit tests: > > - https://bugs.launchpad.net/quantum/+bug/814518 > > I can handle that one, but I'm waiting on some input from Salvatore > regarding the 'spec'. > > ** ** > > My goal is to get these fixes reviewed and merged tomorrow, so please help > out. > > ** ** > > At that point, we should be able to do a bit of sanity testing and cut a > Diable-3 drop, then open the door up for Diablo-4 items. > > ** ** > > First items on the table for Quantum code base in D-4 will be the > client-lib + api extensions, already proposed for merging: > > - > https://code.launchpad.net/~tylesmit/quantum/quantum-client-library-proper > > > - https://code.launchpad.net/~santhoshkumar/quantum/api_extensions > > ** ** > > Diablo-4 will also have a lot of the Quantum related work in Nova. I'm > planning on creating "shadow" quantum blueprints that point to the nova > blueprints so we can easily track what is in our next milestone. > > ** ** > > Dan > > ** ** > > ** ** > > -- > ~~~ > 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 > > > > > -- > Thanks, > Santhosh > > > > > -- > ~~~ > 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 > > -- Somik Behera | Nicira Networks, Inc. | so...@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
Re: [Netstack] reviews, merges, and next steps
I agree with removing portcount tests until we agree on the specification, I have some comments that I'll try to send out next week regarding the API spec alignment. I would say, after this alignment, we should "freeze" the API spec wiki and create a new wiki or future v2 work. Thanks, Somik On Sat, Jul 30, 2011 at 4:40 AM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote: > Hi Dan, > > ** ** > > Regarding but 818321 (Incosistent integer deserialization) I reckon it > would be advisable to follow the 2nd approach you are proposing: “say that > the API does not support passing integer values and change the PortCount > field to be a string” > > ** ** > > However, as you also said in the bug report, PortCount is not anywhere in > the specification. > > So If we all agree we do not want the “get network” operation to return > this information we can just remove PortCount from the API; we could do this > in the effort we are doing to align the API implementation with the > specification (https://bugs.launchpad.net/quantum/+bug/813433). > > ** ** > > On this regard, I would like to reiterate that a thread on the NetStack > Mailing List was already started last week, “Aligning the API code with the > specification”. The API specification was reviewed in order to ensure it was > consistent with the Openstack API, and I would be more than happy to > receive your feedback. > > ** ** > > Cheers, > > Salvatore > > ** ** > > *From:* Dan Wendlandt [mailto:d...@nicira.com] > *Sent:* 30 July 2011 04:04 > *To:* Somik Behera > *Cc:* Salvatore Orlando; Santhosh Kumar M; netstack@lists.launchpad.net > > *Subject:* Re: [Netstack] reviews, merges, and next steps > > ** ** > > Great work on the fixes + reviews folks. > > ** ** > > We now are much closer to having having trunk's unit tests running clean > for a D-3 drop. > > ** ** > > There are two remaining bugs with the unit tests, one of which was > discovered only after the other tests were merged into trunk: > > ** ** > > - https://bugs.launchpad.net/quantum/+bug/818321 > > - https://bugs.launchpad.net/quantum/+bug/814518 > > ** ** > > We're hoping to wrap these up soon and have a drop on monday. > > ** ** > > Dan > > ** ** > > ** ** > > ** ** > > On Fri, Jul 29, 2011 at 10:56 AM, Somik Behera wrote:** > ** > > This is a long awaited branch! It had slipped me, I'll review it soon. > > ** ** > > Thanks, > > Somik > > ** ** > > On Fri, Jul 29, 2011 at 8:45 AM, Salvatore Orlando < > salvatore.orla...@eu.citrix.com> wrote: > > Hi, > > > > I would like to add that the branch that fixes most of the failing tests > is: > https://code.launchpad.net/~salvatore-orlando/quantum/quantum-api/+merge/65979 > > > This branch has been waiting for a review for a week now. > > The “needs fixing” vote that you see on the merge proposal is related to a > previous revision of the branch. Comments in that review have already been > addressed. > > > > Thanks, > > Salvatore > > > > *From:* netstack-bounces+salvatore.orlando=eu.citrix.com@ > lists.launchpad.net [mailto:netstack-bounces+salvatore.orlando= > eu.citrix@lists.launchpad.net] *On Behalf Of *Dan Wendlandt > *Sent:* 29 July 2011 15:43 > *To:* Santhosh Kumar M > *Cc:* netstack@lists.launchpad.net > *Subject:* Re: [Netstack] reviews, merges, and next steps > > > > Thanks for pointing that out Santhosh. To avoid confusion, I updated the > status of the old merge request from "work in progress" to "rejected" to > indicate that it is no longer expected to be merged (this should keep the > history around, as I did not delete the merge request). The new merge > request is still active. Thanks, > > > > Dan > > > > On Thu, Jul 28, 2011 at 9:42 PM, Santhosh Kumar M < > sant...@thoughtworks.com> wrote: > > Hi Dan, > > > > There is one correction in the api-extensions merge prop. > > The latest merge prop is > https://code.launchpad.net/~raxnetworking/quantum/api_extensions. This > branch supports dynamically enabling/disabling extensions for the plugin.* > *** > > > > The link you have mentioned is the old branch, we left that prop to keep a > log of the discussions happened. > > > > On Fri, Jul 29, 2011 at 8:59 AM, Dan Wendlandt wrote: > > Ok, so we're trying to clear a bunch
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. 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//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/~netstac
Re: [Netstack] Aligning the API code with the specification
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//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
[Netstack] Quantum Plugin for OpenStack Dashboard feedback
Thanks Mark, Arvind & team for the work on Dashboard! Apologies that I just got around to reviewing the blueprint. This should provide us with a great demo vehicle for the upcoming OpenStack Design Summit! The initial mocks look good for our Quantum Beta, I just have a few comments around our interactions design scheme that would good to address for our first cut. 1) Networks Tab - I suggest renaming "Delete?" to "Actions" - Much more consistent with rest of dashboard as well as provides the flexibility to have multiple actions grouped here under a single tab, obviously if we have too many actions, we'll have to evolve the UI at a later point. - Keep the existing "delete" link, and in the future we add more links. 2) Network details page - Need a mechanism to go back to the network listing page ( You can always click on "Networks" on left hand menu bar, but it isn't very intuitive, we might have a link on top( like breadcrumbs) that would be helpful... 3) Ports page - Rename "Connects" to Attachment - Merge Attach, Detach, Delete? columns to "Attach" to make the table more consistent with rest of dashboard. * That would make us more consistent with Images, Keys and general dashboard user interaction model. But, I am open to other suggestions. * The column contents would look like this: [Interface drop down] Attach Detach Delete * The links will be grayed out based on the operation the user is allowed to perform, delete operation on already attached port will detach and then delete the port automagically. Otherwise, I am looking forward to the dashboard stuff completing soon! Thanks, Somik -- Somik Behera | Nicira Networks, Inc. | so...@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
Re: [Netstack] Port states
The active states from API definition perspective should be "ACTIVE" and "DOWN" If the OVS plugin has 'UP' thats a bug, please file one and we will bring it inline to API spec. Quantum currently just has 2 supported port-state "ACTIVE" and "DOWN" which map to admin up/down on a port. Thanks, Somik On Tue, Aug 9, 2011 at 10:09 AM, Arvind Somya wrote: > Hello Netstackers, > > I'm trying to write this bit in the dashboard that allows users to toggle > port states, my problem is that while the FakePlugin defines two states > 'ACTIVE' and 'DOWN'.. the ovs plugin defines them as 'UP' and 'DOWN'. > > Is there a way for the dashboard to find out what the supported states are > from the plugin? I couldn't find any methods in the client or the plugin > modules. > > Thanks > Arvind > > -- > Mailing list: > https://launchpad.net/~**netstack<https://launchpad.net/%7Enetstack> > Post to : netstack@lists.launchpad.net > Unsubscribe : > https://launchpad.net/~**netstack<https://launchpad.net/%7Enetstack> > More help : > https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> > -- Somik Behera | Nicira Networks, Inc. | so...@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
Re: [Netstack] AuthZ discussion summary for Quantum
The embedded image was garbled, so I have attached a link to the image. Somik On Fri, Aug 19, 2011 at 2:36 PM, Somik Behera wrote: > Hello All, > > I spent some time on and offline with Nova, Swift & Keystone PTLs > understanding current Keystone use-cases and championing the fine-grained > AuthZ that Quantum will need, here is the summary outcome from those > discussions. Before I dive into that, I would like say the bulk of our AuthN > & AuthZ concerns are already being handled by Salvatore's branch! So, Thanks > Salvatore! > These discussions were along the lines of providing AuthZ of "interfaces" > owned by Nova or (in the future) other interface services. > > *Current Status of AuthZ, wrt Keystone implementation:* > > Keystone is a young( just incubated) project that is focused on addressing > existing use-cases, mostly around AuthN. A notion of "roles" was added as > groups and roles exist in Active Directory and LDAP systems, and Nova > already had some notion of "roles." Keystone is an "integration" service, > that means that Keystone has plugins in the backend to implement Keystone > concepts using Active Directory and other such identity management > solutions. Similar to the notion of Quantum "plugins" > > Roles in Keystone are high-level roles that map to job roles and are > applied on a particular user, for a particular tenant. But the enforcement > of the "role" is left to the individual service, Keystone only provides the > role that a particular user owns, and its the responsibility of the > individual service( Nova, Quantum) to enforce that role. This model of AuthZ > is consistent with the way FileSystems managing a large number of objects > enforce AuthZ where the ACLs are stored with individual files, not in a > separate centralized directory. > > With that said, Keystone team is interested in exploring our use case where > AuthZ is either enforced or orchestrated by Keystone across multiple > underlying services and this would be a good thing to discuss during the > Essex Design Summit. > > *Options for achieving AuthZ in Quantum during diablo time-frame: > ** > Option 1: Short-term solution -** *Introduce a role named "NetworkAdmin" > or "Quantum:NetworkAdmin" This new roles has to be owned by any user > wishing to perform VIF plug operations. The thinking is that the > "NetworkAdmin" role is allocated to the service provider and for the time > being, only the service provider can actually perform "VIF plugging." So, we > have multi-tenancy in our AuthZ APIs for reading and creating network > topologies but not for plugging VIFs. Not quite where we want to be, but it > does provide a realistic Quantum deployment solution in diablo time-frame. > > *Option 2: Medium-term solution* - Quantum performs AuthZ for Network > resources, and calls into Nova to perform network interface AuthZ, and then > performs the VIF plugging. This solution is not ideal and only medium term > as this architecture requires Quantum to contain clients of various > "interface" services, of which Nova is the first interface service. > > The sequence of calls would look someting like this: > > http://www.websequencediagrams.com/index.php?img=mscb96q6O > *Option 3: Long-term solution* - Quantum calls into Keystone for AuthZ and > asks Keystone "Does UserA have VIF-Plug privilege on Tenant-X?" Keystone > either maintain a central repository to service such a request or proxies > the request to individual service, i.e. Nova in this case, in order to > fulfill such a request. This solution needs additional discussion with the > Keystone team. > > > *Summary:* In summary, I would in favor of just having support for Option > 1 in the current diablo time-frame and then we continue to work on more > sophisticated AuthZ solutions. One thing to note is our initial suggestion > of overloading Keystone "roles" to contain information regarding VIF-Plug, > i.e. a role like "nova:VIF-Plug-instance-012-eth0" associated with every > user for every VIF the user is allowed to "plug", was rejected as Keystone > implementations are backed by Active Directory and LDAP systems, which are > not designed for such fine-grained AuthZ and the associated scalability > requirements. > > Thanks, > Somik > > -- Forwarded message -- > From: Ziad Sawalha > Date: Thu, Aug 18, 2011 at 6:00 PM > Subject: Re: [Openstack] AuthZ functionality in Keystone - Re: > [WAS]OpenStack Identity: Keystone API Proposal > To: Vishvananda Ishaya , Somik Behera < > so...@nicira.com> > Cc: "openst...@lists.launchpad.net
Re: [Netstack] Proposing sessions for Openstack design summitq
. Donabe/API models: http://summit.openstack.org/sessions/view/29** > ** > > 2. Continuous integration planning: > http://summit.openstack.org/sessions/view/35 > > > > On top of these two, I would also consider having the following sessions > (in order of importance): > > 1. Higher layer network services (L4/L7), e.g.: Firewall, NAT, VPN** > ** > > 2. Improved authorization framework for Quantum, with a full RBAC > model. > > 3. Quantum API v1.1 > > a. Synchronous vs Asynchronous behaviour and concept of “Operational > Status” > > b. Improvements such as Filtering, Rate Limiting, Resource Links, > pagination > > 4. Cloud Bridging APIs in Quantum > > > > What’s your opinion? > > > > 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 > > > > > > > > -- > ~~~ > 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 > > -- Somik Behera | Nicira Networks, Inc. | so...@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
[Netstack] Pre-summit Quantum & Dashboard integration discussions
Hi All, I just wanted to send few initial thoughts on enhancing our Dashboard integration to better enable the end-user(tenant) to manage their networking( L2, IPAM all together) as well as provide the Cloud Admin a location, where they can interact with Quantum, and perform Quantum specific functions( i.e. use cases specific to the Network Admin) I installed Dashboard with Quantum,Keystone and Nova all working together, after navigating few landmines, I got it running and had some early feedback and I was hoping to collect what ideas other folks in the team had around Dashboard. I know Arvind and Mark Voelker from Cisco have quite a few ideas and I am hoping by the end of summit, we can all together crystallize all the ideas into blueprints for Essex. I am sure there are a lot of thoughts and ideas around how we should integrate Quantum with various OpenStack services, and then how does Dashboard orchestrate all these underlying OpenStack services in a cohesive manner( from networking perspective.) I just wanted to get the discussion started and hopefully, we can tackle the discussions around these flows in the unconference area or together with Salvatore's Quantum integration workflows session <http://summit.openstack.org/sessions/view/78> Quantum-Nova workflow today: 1. OpenStack cloud provider configures QuantumManager as the NetworkManager and the appropriate IPAM service,Nova's IPAM or Melange. 2. Using nova-manage, Cloud “admin” creates global shared networks in nova with a priority & subnet 3. Using nova-manage, Cloud “admin” or tenant “admin” creates tenant specific networks with a priority & subnet 4. Tenant spins up a VM, VM contains appropriate # of nics(multi-nic) based on # of networks the VM is associated with, injected IP, and Vifs plugged into the correct network. Quantum-Dashboard workflow today: 1. OpenStack cloud provider configures Quantum service integration. 2. Tenant logs in with keystone credentials 3. Tenant can view networks owned by the tenant 4. Tenant can create, update, delete tenant owned network & ports 5. Tenant can plug/unplug Vifs to/from networks. Workflow items not supported by dashboard today: 1. A SysPanel UI for "Quantum" only for Network-only admin functionality. 2. Networks created via dashboard are unknown to nova, the networks also are not associated with Nova IPAM or Melange IPAM - This requires that once a Quantum network has been created, user still has to use nova-manage CLI to associate the quantum network within Nova DB and create an associated IP block with the network. 3. A mechanism for dashboard UI to support additional UI for various extensions, in a pluggable manner. While we can discuss what the real workflow should be and what kind of UI we should create, at the summit, I just wanted to open this thread to gather some input ahead of the summit. I am hoping we can merge this discussions with Salvatore's integration workflow discussion or do a unconference session as having a robust UI will definitely help Quantum's adoption as well as Demo's :) Thanks, Somik -- Somik Behera | Nicira Networks, Inc. | so...@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
Re: [Netstack] Pre-summit Quantum & Dashboard integration discussions
inline On Wed, Sep 28, 2011 at 6:23 PM, Dan Wendlandt wrote: > Thanks Somik, > > One question: in the "Quantum-Dashboard workflow today", what determines > how many vNICs a VM is given? > Nothing, Nova knows nothing about networks that are created via Dashboard today, therefore Nova doesn't allocate multiple Nics. This is something we will need to work on in the Essex timeframe. > > In general, I see a couple key areas for improvement in the network > workflow: > > - Be able to use the Dashboard to create a network with a specified subnet. > Under the covers, this would create the Quantum network, and a Melange > subnet. > Agreed, we will finalize the mechanism but yes, creation of subnets and association of subnets with Quantum networks is not happening via the Dashboard today. > > - When creating a VM, you should be able to specify the # of VIFs for that > VM. Each VIF could optionally specify a quantum network to be connected to > and a Melange subnet to get an IP from. This provides the flexibility to > make interesting network topologies, because you no longer have the > requirement that every VM for a project is connected to the same set of > networks. > > This is a little more interesting use case as we will have to see if we want the Dashboard to leverage the OpenStackx API that allows one to specify # of Vif for every VM being launched and then allows the user to specify which networks those Vifs should attached with. This flow is similar to what I prototyped with the "simple quantum > orchestrator" here: http://wiki.openstack.org/QuantumOVSDemo > > One interesting point to discuss is whether L2 networks and subnets should > be tightly coupled in a GUI or not. I can certainly think of cases where > you might not want them to be coupled, but in the common case they are. > Coupled or not, we should be able to create both(L2 network & subnet) from a single interface( CLI, GUI, WS) or atleast create both separately and associate them together. This will be needed to replace the functionality Nova offers today. > > Dan > > > On Wed, Sep 28, 2011 at 5:38 PM, Salvatore Orlando < > salvatore.orla...@eu.citrix.com> wrote: > >> Hi Somik, >> >> ** ** >> >> These are exactly the kind of questions I would like to answer in the >> session I have proposed. >> >> I don’t think we need to schedule a different session in the unconference. >> >> >> ** ** >> >> I hope we can use this thread to precisely define the agenda of the >> session. >> >> ** ** >> >> Salvatore >> >> ** ** >> >> *From:* netstack-bounces+salvatore.orlando= >> eu.citrix@lists.launchpad.net [mailto: >> netstack-bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] *On >> Behalf Of *Devin Carlen >> *Sent:* 29 September 2011 01:19 >> *To:* Somik Behera >> *Cc:* netstack@lists.launchpad.net >> *Subject:* Re: [Netstack] Pre-summit Quantum & Dashboard integration >> discussions >> >> ** ** >> >> Hi all, >> >> ** ** >> >> I have some notes inline for you. >> >> ** ** >> >> On Sep 28, 2011, at 2:59 PM, Somik Behera wrote: >> >> >> >> >> >> Hi All, >> >> I just wanted to send few initial thoughts on enhancing our Dashboard >> integration to better enable the end-user(tenant) to manage their >> networking( L2, IPAM all together) as well as provide the Cloud Admin a >> location, where they can interact with Quantum, and perform Quantum specific >> functions( i.e. use cases specific to the Network Admin) I installed >> Dashboard with Quantum,Keystone and Nova all working together, after >> navigating few landmines, I got it running and had some early feedback and I >> was hoping to collect what ideas other folks in the team had around >> Dashboard. I know Arvind and Mark Voelker from Cisco have quite a few ideas >> and I am hoping by the end of summit, we can all together crystallize all >> the ideas into blueprints for Essex. >> >> ** ** >> >> Yes, we got bit by the Keystone bug a bit. They have committed to >> dropping code by Friday so we should be able to release a Diablo stable >> version of Dashboard by then. >> >> >> >> >> >> I am sure there are a lot of thoughts and ideas around how we should >> integrate Quantum with various OpenStack services, and then how does >> Dashboard orchestrate all these underlying OpenStack services in a cohesive >> manner( from networking perspec
[Netstack] Proposed agenda - NetStack integration with Nova and Dashboard
Hello All, To deliver on the true promise of the Quantum project, we have to ensure that Quantum's networking functionality and features are cohesively integrated with various other pieces of OpenStack ecosystem. This session will go over the great work done during diablo release to integrate Quantum with Nova, Melange and Dashboard and we will try to understand what the real end-user(tenant) workflow should look like. The goal of this session is to come up with tangible blueprints for Essex release that will help us further the ball on delivering upon the true initial promise of creating interesting network topologies using OpenStack components. Here's a rough agenda that I had in mind, I do know Mark Voelker from Cisco and Salvatore Orlando from Citrix have also been doing some thinking along some of these topics, so I hope that there will be good set of ideas on how we deliver on the OpenStack networking vision. - Quantum-Nova workflow today ( using QuantumManager as Nova's Network Manager) - 5 min - Dashboard-Quantum-Nova workflow today - 5 min - Areas of improvement for end-user's (tenant's) network orchestration workflow involving Nova, Quantum & IPAM (Melange) - 15 min - Flexible Multi-nic, multi-network instance creation - 10 min - SysPanel for Quantum Administrator( Network Admin) to interact with networking subsystem - 10 min - Ideas around complete de-coupling of network related configuration information from Nova - 10 min Please do let me know, if there are additional points of discussion around integration workflows, and I'll attempt to ensure those topic get adequate discussion time coverage. Thanks, Somik -- Somik Behera | Nicira Networks, Inc. | so...@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
[Netstack] Etherpad for Quantum workflow and UI in Essex release
Hello All, Here's the etherpad with tasks based on today's workflow and UI requests for Essex release. The next step is to create blueprints for the tasks and find owners for blueprints. Etherpad - http://etherpad.openstack.org/quantum-essex-workflow-ui Thanks, Somik -- Somik Behera | Nicira Networks, Inc. | so...@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
Re: [Netstack] Quantum and keystone
Hi Doude, Keystone will be merged back with additional enhancements to ensure that Quantum and Keystone are usable out of the box. I am curious to know which keystone version are you using, since Keystone hasn't released a Diablo tarball( check today's OpenStack mailing list for reference.) Thanks, Somik On Mon, Oct 24, 2011 at 7:43 AM, Doude wrote: > Hi netstackers, > > I saw that keystone was remove for the Diablo release but why wasn't > remerged to the Essex trunk branch ? > > Regards, > Doude. > > -- > 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 | 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
[Netstack] Quantum workflow and UI for Essex release
Hello Netstackers, I tried to gather the feedback from our flow session into blueprints, so that individual teams can start making progress. We have 2 blueprints that I feel would be pretty important to get right within the Essex time frame, and few other associated blueprints that I have added to our work backlog. Please do let me know, if I have missed or not captured any work items here and then we can hopefully have blueprint owners that will drive the specification and implementation. High priority blueprints: 1) https://blueprints.launchpad.net/quantum/+spec/unified-tenant-facing-network-ui 2) https://blueprints.launchpad.net/quantum/+spec/unified-network-admin-ui Other blueprints: 3) https://blueprints.launchpad.net/quantum/+spec/unified-network-admin-ui 4) https://blueprints.launchpad.net/quantum/+spec/quantum-overview-for-dashboard 5) Independant Melange UI ( I believe we need this at some point in time but it didn't fit under "Quantum" umbrella) I am hoping, Arvind et al. from Cisco, having done great work with initial network UI, would like to tackle blueprint #1 and make our network UI work well. If you are interested in other specific UI functionality, please come forward and volunteer! Here are wireframe references of the upcoming Essex Dashboard release - http://www.slideshare.net/PaulTashima/openstack-dashboard-wireframes-20110928 Thanks, Somik -- Somik Behera | Nicira Networks, Inc. | so...@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
Re: [Netstack] Quantum and keystone
Hi Doude, The diablo tagged keystone had some issues, I believe keystone folks are working on a diablo+ and backporting fixes. As for Quantum, we will focus on keystone integration in essex time frame and that integration may or may not be backported to diablo as Essex keystone already contains breaking schema changes. Thanks, Somik On Tue, Oct 25, 2011 at 1:02 AM, Doude wrote: > Hi Somik and Dan, > > Thanks for your answers. > For the Diablo release, a branch was created for Keystone, it's the > one I use for stable deployment. > For the development environment, I use the trunk version of Keystone. > > Thanks, > Doude. > > On Mon, Oct 24, 2011 at 6:28 PM, Somik Behera wrote: > > Hi Doude, > > > > Keystone will be merged back with additional enhancements to ensure that > > Quantum and Keystone are usable out of the box. > > I am curious to know which keystone version are you using, since Keystone > > hasn't released a Diablo tarball( check today's OpenStack mailing list > for > > reference.) > > > > Thanks, > > Somik > > > > On Mon, Oct 24, 2011 at 7:43 AM, Doude wrote: > >> > >> Hi netstackers, > >> > >> I saw that keystone was remove for the Diablo release but why wasn't > >> remerged to the Essex trunk branch ? > >> > >> Regards, > >> Doude. > >> > >> -- > >> 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 | office: > > 650-390-6790 | cell: 512-577-6645 > > > -- Somik Behera | Nicira Networks, Inc. | so...@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
[Netstack] Authorization (AuthZ) in Quantum
Hello Netstackers, I have the initial blueprint and associated design wiki available for AuthZ in Quantum. I have proposed to implement a simplistic first step AuthZ capability in Quantum leveraging Keystone tokens and roles. Blueprint -- https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum Design wiki -- http://wiki.openstack.org/QuantumAuthZ Thanks, Somik -- Somik Behera | Nicira Networks, Inc. | so...@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
[Netstack] [Bug 921743] [NEW] Quantum API 1.0 is broken in latest Quantum Essex trunk
Public bug reported: As per our public Quantum 1.0 API specification, our success return codes on create call is HTTP 200 OK Reference - http://docs.openstack.org/incubation/openstack- network/developer/quantum-api-1.0/quantum-api-guide-trunk.pdf Current Behavior: The success code is hard-coded in Quantum API, irrespective of API version of 1.0 or 1.1, therefore the success response code while correct for API v1.1, stands incorrect for API v1.0 Reference( Quantum Essex-2) - https://github.com/openstack/quantum/blob/essex-2/quantum/api/api_common.py#L103 Recommended Solution: We will need a mechanism to specify API version specific 'HeaderSerializer' class that contains correct response codes for that particular version. Thanks, Somik ** Affects: quantum Importance: High Assignee: Netstack (netstack) Status: New -- You received this bug notification because you are a member of Netstack, which is a bug assignee. https://bugs.launchpad.net/bugs/921743 Title: Quantum API 1.0 is broken in latest Quantum Essex trunk Status in OpenStack Quantum (virtual network service): New Bug description: As per our public Quantum 1.0 API specification, our success return codes on create call is HTTP 200 OK Reference - http://docs.openstack.org/incubation/openstack- network/developer/quantum-api-1.0/quantum-api-guide-trunk.pdf Current Behavior: The success code is hard-coded in Quantum API, irrespective of API version of 1.0 or 1.1, therefore the success response code while correct for API v1.1, stands incorrect for API v1.0 Reference( Quantum Essex-2) - https://github.com/openstack/quantum/blob/essex-2/quantum/api/api_common.py#L103 Recommended Solution: We will need a mechanism to specify API version specific 'HeaderSerializer' class that contains correct response codes for that particular version. Thanks, Somik To manage notifications about this bug go to: https://bugs.launchpad.net/quantum/+bug/921743/+subscriptions -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
