[openstack-dev] [nova] Backwards incompatible API changes
dms at danplanet.com
Thu Mar 20 22:45:11 UTC 2014
> If we managed to break Horizon, its likely we've broken (or will break)
> other people's scripts or SDKs.
> The patch was merged in October (just after Icehouse opened) and so has
> been used in clouds that do CD for quite a while. After some discussion
> on IRC I think we'll end up having to leave this backwards incompatible
> change in there - given there are most likely users who now rely on
> both sets of behaviour there is no good way to get out of this
> situation. I've added a note to the Icehouse release notes.
So, my first reaction was to keep this change since we've had it in the
wild since October, we know that we have CDing public and private
clouds, and because it makes us match our own docs. The original
decision was made to fix the problem, knowing that it might break a
client, even though it wasn't expected that we would in reality. That
clearly wasn't quite right.
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.
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.
I'm really okay with any of the three options, but given that the
revert-or-not dichotomy ends up definitely breaking someone, I think the
third option is what I'd prefer. Given that we're already looking at a
change, lets make it a change that is least offensive.
More information about the OpenStack-dev