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.lo...@rackspace.com<mailto:brandon.lo...@rackspace.com>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, March 19, 2015 at 6:20 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@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 <doug...@parksidesoftware.com<mailto:doug...@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 <gkot...@vmware.com<mailto:gkot...@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 <gkot...@vmware.com<mailto:gkot...@vmware.com>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, March 19, 2015 at 2:32 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@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 <gkot...@vmware.com<mailto:gkot...@vmware.com>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
