Open Stack

On Fri, 21 Feb 2014 13:03:31 -0800
Joe Gordon <joe.gordon0 at gmail.com> wrote:
> > 1) Discussions about the v2 and v3 APIs at the in-person Nova meetup
> > last week made me come to the realization that v2 won't be going
> > away *any* time soon.  In some cases, users have long term API
> > support expectations (perhaps based on experience with EC2).  In
> > the best case, we have to get all of the SDKs updated to the new
> > API, and then get to the point where everyone is using a new enough
> > version of all of these SDKs to use the new API.  I don't think
> > that's going to be quick.
> 
> Unless we specifically work with SDKs I don't think they will support
> V3 until we mark it as stable. So I think we are in a bit of a chicken
> and egg situation.

Yes and we also seem to be concerned about something (people not move
off the V2 API in reasonable time) which *might* happen. And that its
not something we can influence. Also the longer we leave the V2 API as
the only supported version, the bigger the problem becomes.

> > We really don't want to be in a situation where we're having to
> > force any sort of migration to a new API.  The new API should be
> > compelling enough that everyone *wants* to migrate to it.  If
> > that's not the case, we haven't done our job.
> >
> > 2) There's actually quite a bit still left on the existing v3 todo
> > list. We have some notes here:
> >
> > https://etherpad.openstack.org/p/NovaV3APIDoneCriteria
> >
> > One thing is nova-network support.  Since nova-network is still not
> > deprecated, we certainly can't deprecate the v2 API without
> > nova-network support in v3.  We removed it from v3 assuming
> > nova-network would be deprecated in time.
> >
> > Another issue is that we discussed the tasks API as the big new API
> > feature we would include in v3.  Unfortunately, it's not going to be
> > complete for Icehouse.  It's possible we may have some initial parts
> > merged, but it's much smaller scope than what we originally
> > envisioned. Without this, I honestly worry that there's not quite
> > enough compelling functionality yet to encourage a lot of people to
> > migrate.
> >
> 
> Can we get more people to work in tasks and try to get it out in
> icehouse?

It would most likely mean having quite a few feature freeze exceptions.

> If we want to go back to having only 1 API at a specific release in
> the future, what about setting a deadline for ourselves to get v3 out
> in Juno no matter what?

Well I think we should AND keep the scope of V3 API changes as small as
possible (eg tasks and nova-network). 

If we take the route of not releasing the V3 API and trying to backport
features we like from it we actually lose a lot of improvements. Eg
cleaning up the API so its consistent to users can't really be done in
a backward compatible way. Also input validation improvements because
we'll start breaking apps. 

On the other hand if we start saying that its ok to start making 
backwards incompatible changes to fix these sorts of issues then I
think its not that different to just setting a reasonable deprecation
deadline for the V2 API and telling people to move to the V3 API.

In terms of reducing future code duplication issues we could get the V2
API code to be able to load V3 plugins. Where the interface is exactly
the same (and this would be true for new plugins and some of the more
recent ones, we don't need a V2 version, just a V3 version). Assuming
XML support is deprecated in Juno which it now is.

If we wanted to we could even slowly break the V2 API (in say
extensions which are rarely used) so its slowly replaced by the V3
API by marking it as deprecated and then eventually getting the V2 API
to load the V3 version.

This probably wouldn't work for the core of the V2 API - as its the
same as just saying move to the V3 API. But if the maintenance burden
in Nova is the big issue and we *really* want to keep supporting the
V2 API, then we could create a translation V2<->V3 proxy service. So
after what we believe is a reasonable warning period, rip out the V2
API and replace with a proxy which converts V2 requests to V3 ones and
does V3->V2 translation for responses. Not as efficient, but removes
a lot of the maintenance overhead from Nova itself.

Chris