Open Stack

Hi,
Until now all changes to the API’s have been made in separate extensions and not in the base. These should actually be on the provider networks extension.
First this code is not supported by any of the plugins other than the ML2 (I am not sure if this break things – it certain broke the unit tests). Secondly these two changes do not have open source reference implementations (but that is digressing from the problem).
I really think that we need to revert these and have the extensions done in the standard fasion.
Thanks
Gary


From: Brandon Logan <brandon.logan at RACKSPACE.COM<mailto:brandon.logan at RACKSPACE.COM>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, March 19, 2015 at 6:20 PM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions


​Isn't this argument as to whether those fields should be turned off/on, versus just always being on?  Are there any guidelines as to what fields are allowed to be added in that base resource attr map?  If ML2 needs these and other fields, should they just always be on?


Thanks,

Brandon

________________________________
From: Doug Wiegley <dougwig at parksidesoftware.com<mailto:dougwig at parksidesoftware.com>>
Sent: Thursday, March 19, 2015 11:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions

Hi Gary,

First I’m seeing these, but I don’t see that they’re required on input, unless I’m mis-reading those reviews.  Additional of new output fields to a json object, or adding optional inputs, is not generally considered to be backwards incompatible behavior in an API. Does OpenStack have a stricter standard on that?

Thanks,
doug


On Mar 19, 2015, at 6:37 AM, Gary Kotton <gkotton at vmware.com<mailto:gkotton at vmware.com>> wrote:

Hi,
Changed the subject so that it may draw a little attention.
There were 2 patches approved that kind of break the API (in my humble opinion):
https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420/
In both of these two new fields were added to the base attributes – mtu and vlan_transparency
Reverts for them are:
https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 (vlan transparency).
In my opinion these should be added as separate extensions.
Thanks
Gary

From: Gary Kotton <gkotton at vmware.com<mailto:gkotton at vmware.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, March 19, 2015 at 2:32 PM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Hi,
This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary

From: Gary Kotton <gkotton at vmware.com<mailto:gkotton at vmware.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, March 19, 2015 at 1:14 PM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [Neutron] VLAN transparency support

Hi,
It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others.
I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (https://review.openstack.org/#/c/165776/) – please feel free to knack if it is invalid.
Thanks
Gary
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150319/42b23d6e/attachment.html>