[openstack-dev] [api] Minor changes to API
dkranz at redhat.com
Tue Apr 21 00:52:37 UTC 2015
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
> > 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
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
> 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?
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev