Open Stack

Hi Doug,
On Thu, 19 Mar 2015 10:01:54 -0600
Doug Wiegley <dougwig at parksidesoftware.com> wrote:

> 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?

So speaking from a Nova (and more general) API point of view where
we're probably a bit longer along the extensions/microversioning path,
I think even with backwards compatibility it is still an issue. For
example, without some sort of co-operative and strong input validation
are you going to detect when someone sends a new parameter that is
simply mispelled and all the other extensions assume that someone will
look after it and return an appropriate rather than let it just through.

Over time we've found a few examples even in our api request samples
typos (which feeds into the docs) which are not detected just because
of this situation.

Chris

> 
> 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
> > <https://review.openstack.org/#/c/154921>/ and
> > https://review.openstack.org/#/c/158420
> > <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
> > <https://review.openstack.org/165801> (mtu) and
> > https://review.openstack.org/165776
> > <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
> > <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
> > <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
> > <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
>