On 04/20/2015 08:07 PM, Ian Wells wrote:
On 20 April 2015 at 15:23, Matthew Treinish <mtrein...@kortar.org
<mailto:mtrein...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
