<div dir="ltr">On 20 April 2015 at 15:23, Matthew Treinish <span dir="ltr"><<a href="mailto:mtreinish@kortar.org" target="_blank">mtreinish@kortar.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Apr 20, 2015 at 03:10:40PM -0700, Ian Wells wrote:<br>
> It would be nice to have a consistent policy here; it would make future<br>
> decision making easier and it would make it easier to write specs if we<br>
> knew what was expected and the possible implementations weren't up for<br>
> (quite so much) debate.  For different reasons, Neutron extensions are also<br>
> not favoured, so there's no clear cut choice to make.<br>
<br>
</div></div>Uhm, there is: <a href="https://wiki.openstack.org/wiki/APIChangeGuidelines" target="_blank">https://wiki.openstack.org/wiki/APIChangeGuidelines</a><br>
and if you read that adding attrs without advertising it (using an<br>
extension, microversion, or whatever) is not an allowed change.</blockquote><div><br></div><div>It is also not an unallowed change (given that there's a section that appears to define what an unallowed attribute change is).  The page reads very awkwardly.<br><br>Whatever your preference might be, I think it's best we lose the ambiguity.  And perhaps advertise that page a little more widely, actually - I hadn't come across it in my travels.  And perhaps improve its air of authority: rules on this subject should probably live somewhere in a repo so that it's clear there's consensus for changes.  Currently anyone can change it for any reason, and two years after the last substantive change it's hard to say who even knew it was being changed, let alone whether they agreed.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Just adding<br>
things without a new extension or microversion makes the end user story terrible<br>
because it puts the burden completely on the user to try and figure out which<br>
version 2 (or whatever it currently is marked as) of the api the cloud they're<br>
using speaks. Think about it if it were a library, that just started adding<br>
things to it's interfaces without bumping any version. Even if it was a<br>
backwards compatible addition you would still expect the version to increment to<br>
indicate that the new stuff was there and available for use.<br></blockquote><div><br></div><div>I appreciate your point and I'd be happy for that to be more obviously our position.  <br><br>The issue that the MTU change hit was the conflict between this general principle and the consensus in its project.  Neutron's core team was giving a strong 'no more extensions' vibe at the last summit, Neutron hasn't got microversioning, and the content of that document is two years old and apparently not very widely known by reviewers as well as me.  No choice would have been right.<br><br>So again, how about we fix that document up and put it somewhere where it receives a bit more control and attention?<br>-- <br></div><div>Ian.<br></div></div></div></div>