Open Stack

On 04/20/2015 08:07 PM, Ian Wells wrote:
> On 20 April 2015 at 15:23, Matthew Treinish <mtreinish at kortar.org 
> <mailto: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.
This page has some kind of authority as it is linked to from 
https://wiki.openstack.org/wiki/Governance/Approved/APIStability. At 
that time the guidelines were a work in progress but clearly at this 
point it belongs in a more controlled repo. That said, this document has 
been referenced many times on the dev list and I am not sure that just 
moving it to a repo would increase awareness. It would also need to be 
more advertised.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150420/46d7402f/attachment.html>