[openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

Christopher Yeoh cbkyeoh at gmail.com
Mon Mar 3 21:25:47 UTC 2014

On Mon, 03 Mar 2014 12:32:04 -0500
Russell Bryant <rbryant at redhat.com> wrote:
> The v3 API effort has produced a lot of excellent work.  However, the
> majority opinion seems to be that we should avoid the cost of
> maintaining two APIs if at all possible.  We should apply what has
> been learned to the existing API where we can and focus on making v2
> something that we can continue to maintain for years to come.

I'll respond to the technical points raised later, but I do
want to point out now that I think this is a false dichotomy. That it is
incorrect to say that the only way to avoid the cost of maintaining two
APIs is to keep only the V2 API. Especially when the discussion
then proceeds around being able to make backwards incompatible changes
(deprecation) - which is a doing a major version bump whether we call
it that or not and is keeping multiple versions around.

> We recognize and accept that it is a failure of Nova project
> leadership that we did not come to this conclusion much sooner.  We
> hope to have learned from the experience to help avoiding a situation
> like this happening again in the future.

The V3 API development work was encouraged and endorsed at both the
Havana and Icehouse (and at Icehouse most of the V3 API patches that
form the core of the API had already merged) and everyone had ample
opportunity to comment or object then. 

But what I think disappoints me most is the way that this discussion
has been approached. That the people who have done the most
work on both the V3 and V2 API code in the last couple of cycles were
not consulted first to see what could be done to address the concerns
around dual maintenance. And instead an assertion was made that all of
the work done for V3 would have to be dropped because of dual
maintenance concerns without even trying to measure or explain what
that dual maintenance overhead is.


More information about the OpenStack-dev mailing list