On Mon, Apr 20, 2015 at 03:10:40PM -0700, Ian Wells wrote: > On 20 April 2015 at 13:02, Kevin L. Mitchell <[email protected]> > wrote: > > > On Mon, 2015-04-20 at 13:57 -0600, Chris Friesen wrote: > > > > However, minor changes like that could still possibly break clients > > that are not > > > > expecting them. For example, a client that uses the json response as > > arguments > > > > to a method via **kwargs would start seeing TypeErrors for unexpected > > arguments. > > > > > > Isn't this what microversions were intended to solve? > > > > Yes. > > > > > I'm relatively recent with OpenStack, so I don't have the history. Did > > anyone > > > ever consider explicitly allowing new attributes to be added to > > responses? > > > > The problem is advertising that this information is available. > > > There are some cases where that's not necessary: a call returns a JSON > dict. If, when the dict does not contain the key, some backward compatible > behaviour is assumed, then you are in fact 100% backward compatible. > > There are other more ambiguous cases, such as setting an attribute that > doesn't exist in some cases and getting a failure response; there it's nice > to be able to tell in advance via a detection call what to expect. > > Anyway, I've been bitten by not knowing the unwritten rules so I do agree > we could use a policy. > > That's > > why, in the past, nova required a new extension even if all you were > > doing was adding an attribute, and that's why we want a new microversion > > nowadays. > > > Depends on your project. For Neutron: > > - some IPv6 changes introduced new (settable) subnet attributes without a > bump in version; these were merged in and are now released in Juno > - the recent VLAN and MTU changes introduced new network attributes without > a bump in version; these were certainly argued about as a break with > backward compatibility (and eventually became extensions, though for other > reasons than simply that one) > - extensions in Neutron can be used to add attributes without changing the > core interface; extension detection APIs exist to make planning easier > > It would be nice to have a consistent policy here; it would make future > decision making easier and it would make it easier to write specs if we > knew what was expected and the possible implementations weren't up for > (quite so much) debate. For different reasons, Neutron extensions are also > not favoured, so there's no clear cut choice to make.
Uhm, there is: https://wiki.openstack.org/wiki/APIChangeGuidelines and if you read that adding attrs without advertising it (using an extension, microversion, or whatever) is not an allowed change. Just adding things without a new extension or microversion makes the end user story terrible because it puts the burden completely on the user to try and figure out which version 2 (or whatever it currently is marked as) of the api the cloud they're using speaks. Think about it if it were a library, that just started adding things to it's interfaces without bumping any version. Even if it was a backwards compatible addition you would still expect the version to increment to indicate that the new stuff was there and available for use. -Matt Treinish
pgpgK3_wSwOQj.pgp
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
