On 03/21/2014 02:18 PM, Chris Behrens wrote:
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?
- Chris
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.
There was a related discussion about getting more eyes on changes that
propose to be excepted from the API stability guidelines here
http://lists.openstack.org/pipermail/openstack-dev/2014-January/023254.html
-David
On Mar 21, 2014, at 10:34 AM, David Kranz <[email protected]
<mailto:[email protected]>> wrote:
On 03/21/2014 05:04 AM, Christopher Yeoh wrote:
On Thu, 20 Mar 2014 15:45:11 -0700
Dan Smith <[email protected] <mailto:[email protected]>> wrote:
I know that our primary delivery mechanism is releases right now, and
so if we decide to revert before this gets into a release, that's
cool. However, I think we need to be looking at CD as a very important
use-case and I don't want to leave those folks out in the cold.
I don't want to cause issues for the CD people, but perhaps it won't be
too disruptive for them (some direct feedback would be handy). The
initial backwards incompatible change did not result in any bug reports
coming back to us at all. If there were lots of users using it I think
we could have expected some complaints as they would have had to adapt
their programs to no longer manually add the flavor access (otherwise
that would fail). It is of course possible that new programs written in
the meantime would rely on the new behaviour.
I think (please correct me if I'm wrong) the public CD clouds don't
expose that part of API to their users so the fallout could be quite
limited. Some opinions from those who do CD for private clouds would be
very useful. I'll send an email to openstack-operators asking what
people there believe the impact would be but at the moment I'm thinking
that revert is the way we should go.
Could we consider a middle road? What if we made the extension
silently tolerate an add-myself operation to a flavor, (potentially
only) right after create? Yes, that's another change, but it means
that old clients (like horizon) will continue to work, and new
clients (which expect to automatically get access) will continue to
work. We can document in the release notes that we made the change to
match our docs, and that anyone that *depends* on the (admittedly
weird) behavior of the old broken extension, where a user doesn't
retain access to flavors they create, may need to tweak their client
to remove themselves after create.
My concern is that we'd be digging ourselves an even deeper hole with
that approach. That for some reason we don't really understand at the
moment, people have programs which rely on adding flavor access to a
tenant which is already on the access list being rejected rather than
silently accepted. And I'm not sure its the behavior from flavor access
that we actually want.
But we certainly don't want to end up in the situation of trying to
work out how to rollback two backwards incompatible API changes.
Chris
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?
Perhaps it would be a good time to
reviewhttps://wiki.openstack.org/wiki/Governance/Approved/APIStabilityand
the details ofhttps://wiki.openstack.org/wiki/APIChangeGuidelinesto
make sure they still reflect the will of the TC and our community.
-David
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
