[openstack-dev] [nova] Future of the Nova API

Christopher Yeoh cbkyeoh at gmail.com
Tue Feb 25 01:31:37 UTC 2014


On Mon, 24 Feb 2014 18:17:34 -0500
Sean Dague <sean at dague.net> wrote:

> On 02/24/2014 06:13 PM, Chris Friesen wrote:
> > On 02/24/2014 04:59 PM, Sean Dague wrote:
> > 
> >> So, that begs a new approach. Because I think at this point even
> >> if we did put out Nova v3, there can never be a v4. It's too much,
> >> too big, and doesn't fit in the incremental nature of the project.
> > 
> > Does it necessarily need to be that way though?  Maybe we bump the
> > version number every time we make a non-backwards-compatible change,
> > even if it's just removing an API call that has been deprecated for
> > a while.
> 
> So I'm not sure how this is different than the keep v2 and use
> microversioning suggestion that is already in this thread.

For non backwards compatible changes I think the difference is in how
the user accesses the API. When only make major changes when bumping
the major version then they know for sure that if they access

/v3/foo

then they're app will work. If /v3 doesn't exist then they know it's
not supported.

Whereas if we make backwards incompatible changes within a major
version then they have to start checking the microversion first. And
if experience is anything to go with we end up with user code that gets
overly conservative about checking versions (eg checking against exact
versions or not working with later versions), "just in case".

Note that bumping the major version in the future does not
necessarily mean a rework of the magnitude that we have had for V3. The
V2->V3 transition is different because we want to change a *lot* of the
API.

We now have an architecture in the V3 API which is quite a bit more
flexible. So say a theoretical example of where we wanted to change the
data return from shelve in a backwards incompatible way (in practice
I don't think we'd bump a major version just for one change). We could
present a /v4 interface that was exactly the same as /v3 except for
what shelve provides and the only code duplication would be that
required for the new shelve functionality. All the "v3 plugins" would
load into the /v4 namespace. (It's most likely not worth doing this for
the v2/v3 transition because so much has changed and we cant retrofit
better input validation).

So those who want the deprecated behaviour continue to access
everything via /v3, those who want the new behaviour access it via /v4.
Its a clean delineation for users and they never accidentally get new
backwards incompatible behaviour through the old resource path. Either
its there (and supported) or /v3 doesn't exist and they need to update
their app which if they don't use the shelve functionality is trivial
(just point at /v4 instead of /v3) which is really just the equivalent
of linking your program against libfoo.2.so instead of libfoo.1.so. And
we don't have extra test load except for the shelve delta because the
code is all exactly the same.

For backwards compatible changes, microversions are certainly useful
though.

Chris



More information about the OpenStack-dev mailing list