<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 04/20/2015 08:07 PM, Ian Wells
wrote:<br>
</div>
<blockquote
cite="mid:CAPoubz64dbBZveLO4RuQLXcVmjy61dgjhG+Y2paT5u17q8nu+g@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">On 20 April 2015 at 15:23, Matthew Treinish <span
dir="ltr"><<a moz-do-not-send="true"
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">
<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 moz-do-not-send="true"
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>
</div>
</div>
</div>
</div>
</blockquote>
This page has some kind of authority as it is linked to from
<a class="moz-txt-link-freetext" href="https://wiki.openstack.org/wiki/Governance/Approved/APIStability">https://wiki.openstack.org/wiki/Governance/Approved/APIStability</a>. 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.<br>
<br>
-David<br>
<blockquote
cite="mid:CAPoubz64dbBZveLO4RuQLXcVmjy61dgjhG+Y2paT5u17q8nu+g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote"> 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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>