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

John Garbutt john at johngarbutt.com
Thu Mar 6 11:54:02 UTC 2014

On 5 March 2014 03:44, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> But this plan is certainly something I'm happy to support.


On 5 March 2014 03:44, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> So I think this a good compromise to keep things moving. Some aspects
> that we'll need to consider:
> - We need more tempest coverage of Nova because it doesn't cover all of
>   the Nova API yet. We've been working on increasing this as part of
>   the V3 API work anyway (and V2 support is an easyish side effect).
>   But more people willing to write tempest tests are always welcome :-)


This seems key to making sure we do any "v2" compatibility right.

> - I think in practice this will probably mean that V3 API is
>   realistically only a K rather than J thing - just in terms of allowing
>   a reasonable timeline to not only implement the v2 compat but get
>   feedback from deployers.


One extra thing we need to consider, how to deal with new APIs while
we go through this transition?

I don't really have any answers to hand, but I want v3 to get released
ASAP, and I want people to easily add API features to Nova. If the
proxy is ready early, maybe we could have people implement only v3
extensions, then optionally add v2 extension that just uses wraps the
v2 proxy + v3 extensions.

> - I'm not sure how this affects how we approach the tasks work. Will
>   need to think about that more.


Its a thread of its own, but I think improving instance-actions, still
leaving tasks for v3, might be the way forward.

While we need to avoid feature creep, I still think if we add tasks
into v3 in the right way, it could be what makes people move to v3.

One more thing... I wonder if all new extensions should be considered
"experimental" (or version 0) for at least one cycle. In theory, that
should help us avoid some of the worst mistakes when adding new APIs.


More information about the OpenStack-dev mailing list