On Fri, 21 Feb 2014 13:03:31 -0800 Joe Gordon <joe.gord...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
