<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 April 2015 at 13:02, Kevin L. Mitchell <span dir="ltr"><<a href="mailto:kevin.mitchell@rackspace.com" target="_blank">kevin.mitchell@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 2015-04-20 at 13:57 -0600, Chris Friesen wrote:<br>
> > However, minor changes like that could still possibly break clients that are not<br>
> > expecting them.  For example, a client that uses the json response as arguments<br>
> > to a method via **kwargs would start seeing TypeErrors for unexpected arguments.<br>
><br>
> Isn't this what microversions were intended to solve?<br>
<br>
</span>Yes.<br>
<span class=""><br>
> I'm relatively recent with OpenStack, so I don't have the history.  Did anyone<br>
> ever consider explicitly allowing new attributes to be added to responses?<br>
<br>
</span>The problem is advertising that this information is available.  </blockquote><div><br></div><div>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.<br><br></div>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.<br><br>Anyway, I've been bitten by not knowing the unwritten rules so I do agree we could use a policy.<br><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That's<br>
why, in the past, nova required a new extension even if all you were<br>
doing was adding an attribute, and that's why we want a new microversion<br>
nowadays.</blockquote><div><br></div><div>Depends on your  project.  For Neutron:<br><br></div><div>- some IPv6 changes introduced new (settable) subnet attributes without a bump in version; these were merged in and are now released in Juno<br></div><div>- 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)<br></div><div>- extensions in Neutron can be used to add attributes without changing the core interface; extension detection APIs exist to make planning easier<br><br></div><div>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.<br>-- <br></div><div>Ian.<br></div></div></div></div>