[openstack-dev] [Neutron] Neutron extenstions

Ian Wells ijw.ubuntu at cack.org.uk
Thu Mar 19 18:24:16 UTC 2015


There are precedents for this.  For example, the attributes that currently
exist for IPv6 advertisement are very similar:

- added during the run of a stable Neutron API
- properties added on a Neutron object (MTU and VLAN affect network, but
IPv6 affects subnet - same principle though)
- settable, but with defaults so they're optional
- turn up in output when the subnet information is fetched

With the one caveat (write your code to ignore properties you don't
understand) this seems to address backward compatibility in both the IPv6
and the MTU/VLAN attribute changes - if you completely ignore the attribute
behaviour is enough the way it used to be that your app won't break.

Now, it may be that no-one noticed the ipv6 changes as they went through,
but given the long debate about what the attributes should look like at the
time they did get reasonable attention.  Do we want to change the rules for
future API changes?
-- 
Ian.


On 19 March 2015 at 10:07, Gary Kotton <gkotton at vmware.com> wrote:

>  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>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: Thursday, March 19, 2015 at 6:20 PM
> To: OpenStack List <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>
> *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> 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>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: Thursday, March 19, 2015 at 2:32 PM
> To: OpenStack List <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>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: Thursday, March 19, 2015 at 1:14 PM
> To: OpenStack List <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?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 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/2a4cce6f/attachment.html>


More information about the OpenStack-dev mailing list