[openstack-dev] [nova] Backwards incompatible API changes
cbehrens at codestud.com
Fri Mar 21 18:18:32 UTC 2014
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?
On Mar 21, 2014, at 10:34 AM, David Kranz <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> 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 review https://wiki.openstack.org/wiki/Governance/Approved/APIStability and the details of https://wiki.openstack.org/wiki/APIChangeGuidelines to make sure they still reflect the will of the TC and our community.
>> OpenStack-dev mailing list
>> 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