<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 03/21/2014 02:18 PM, Chris Behrens
wrote:<br>
</div>
<blockquote
cite="mid:7A3134BC-D6F3-495F-8CE3-D3B566AA0837@codestud.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div><br>
</div>
<div>FWIW, I’m fine with any of the options posted. But I’m
curious about the precedence that reverting would create. It
essentially sounds like if we release a version with an API bug,
the bug is no longer a bug in the API and the bug becomes a bug
in the documentation. The only way to ‘fix' the API then would
be to rev it. Is that an accurate representation and is that
desirable? Or do we just say we take these on a case-by-case
basis?</div>
<div><br>
</div>
<div>- Chris</div>
</blockquote>
It has to be on a case-by-case basis. Obviously if fixing a security
bug required an api change we would make it. But as the eco-system
around the OpenStack APIs continue to grow, there should be a higher
and higher bar based on what is gained by the change. In my view, we
are well past the point where the value of a change like this one
would justify violating the API stability guidelines.<br>
<br>
There was a related discussion about getting more eyes on changes
that propose to be excepted from the API stability guidelines here
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-dev/2014-January/023254.html">http://lists.openstack.org/pipermail/openstack-dev/2014-January/023254.html</a><br>
<br>
-David<br>
<blockquote
cite="mid:7A3134BC-D6F3-495F-8CE3-D3B566AA0837@codestud.com"
type="cite">
<div><br>
</div>
<br>
<div>
<div>On Mar 21, 2014, at 10:34 AM, David Kranz <<a
moz-do-not-send="true" href="mailto:dkranz@redhat.com">dkranz@redhat.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-size: 12px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-stroke-width:
0px;">On 03/21/2014 05:04 AM, Christopher Yeoh wrote:<br>
<blockquote type="cite">On Thu, 20 Mar 2014 15:45:11 -0700<br>
Dan Smith <<a moz-do-not-send="true"
href="mailto:dms@danplanet.com">dms@danplanet.com</a>>
wrote:<br>
<blockquote type="cite">I know that our primary delivery
mechanism is releases right now, and<br>
so if we decide to revert before this gets into a
release, that's<br>
cool. However, I think we need to be looking at CD as a
very important<br>
use-case and I don't want to leave those folks out in
the cold.<br>
<br>
</blockquote>
I don't want to cause issues for the CD people, but
perhaps it won't be<br>
too disruptive for them (some direct feedback would be
handy). The<br>
initial backwards incompatible change did not result in
any bug reports<br>
coming back to us at all. If there were lots of users
using it I think<br>
we could have expected some complaints as they would have
had to adapt<br>
their programs to no longer manually add the flavor access
(otherwise<br>
that would fail). It is of course possible that new
programs written in<br>
the meantime would rely on the new behaviour.<br>
<br>
I think (please correct me if I'm wrong) the public CD
clouds don't<br>
expose that part of API to their users so the fallout
could be quite<br>
limited. Some opinions from those who do CD for private
clouds would be<br>
very useful. I'll send an email to openstack-operators
asking what<br>
people there believe the impact would be but at the moment
I'm thinking<br>
that revert is the way we should go.<br>
<br>
<blockquote type="cite">Could we consider a middle road?
What if we made the extension<br>
silently tolerate an add-myself operation to a flavor,
(potentially<br>
only) right after create? Yes, that's another change,
but it means<br>
that old clients (like horizon) will continue to work,
and new<br>
clients (which expect to automatically get access) will
continue to<br>
work. We can document in the release notes that we made
the change to<br>
match our docs, and that anyone that *depends* on the
(admittedly<br>
weird) behavior of the old broken extension, where a
user doesn't<br>
retain access to flavors they create, may need to tweak
their client<br>
to remove themselves after create.<br>
</blockquote>
My concern is that we'd be digging ourselves an even
deeper hole with<br>
that approach. That for some reason we don't really
understand at the<br>
moment, people have programs which rely on adding flavor
access to a<br>
tenant which is already on the access list being rejected
rather than<br>
silently accepted. And I'm not sure its the behavior from
flavor access<br>
that we actually want.<br>
<br>
But we certainly don't want to end up in the situation of
trying to<br>
work out how to rollback two backwards incompatible API
changes.<br>
<br>
Chris<br>
</blockquote>
Nope. IMO we should just accept that an incompatible change
was made that should not have been, revert it, and move on.
I hope that saying our code base is going to support CD does
not mean that any incompatible change that slips through our
very limited gate cannot be reverted. October was a while
back but I'm not sure what principle we would use to draw
the line. I am also not sure why this is phrased as a CD vs.
not issue. Are the *users* of a system that happens to be
managed using CD thought to be more tolerant of their code
breaking?<br>
<br>
Perhaps it would be a good time to review<span
class="Apple-converted-space"> </span><a
moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Governance/Approved/APIStability">https://wiki.openstack.org/wiki/Governance/Approved/APIStability</a><span
class="Apple-converted-space"> </span>and the details of<span
class="Apple-converted-space"> </span><a
moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/APIChangeGuidelines">https://wiki.openstack.org/wiki/APIChangeGuidelines</a><span
class="Apple-converted-space"> </span>to make sure they
still reflect the will of the TC and our community.<br>
<br>
-David<br>
<blockquote type="cite">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>