[openstack-dev] [nova] Backwards incompatible API changes
dkranz at redhat.com
Fri Mar 21 20:24:31 UTC 2014
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
> On Mar 21, 2014, at 10:34 AM, David Kranz <dkranz at redhat.com
> <mailto:dkranz at redhat.com>> wrote:
>> On 03/21/2014 05:04 AM, Christopher Yeoh wrote:
>>> On Thu, 20 Mar 2014 15:45:11 -0700
>>> Dan Smith <dms at danplanet.com <mailto:dms at danplanet.com>> 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.
>> 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
>> the details ofhttps://wiki.openstack.org/wiki/APIChangeGuidelinesto
>> make sure they still reflect the will of the TC and our community.
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev