Open Stack

On 20 April 2015 at 15:23, Matthew Treinish <mtreinish at kortar.org> wrote:

> On Mon, Apr 20, 2015 at 03:10:40PM -0700, Ian Wells wrote:
> > 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.


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.

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.

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

I appreciate your point and I'd be happy for that to be more obviously our
position.

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.

So again, how about we fix that document up and put it somewhere where it
receives a bit more control and attention?
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150420/cd1104c1/attachment.html>