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

Christopher Lefelhocz christopher.lefelhoc at RACKSPACE.COM
Wed Mar 5 13:52:46 UTC 2014

I like this plan as it addresses my primary concern of getting deployments
comfortable with the transition.

We don't mention SDKs in the plan.  It seems like getting at least one SDK
to use v3 would provide us additional data in the transition.  There is
clear risk associated with that, but it may help to work out any
additional issues that crop up.


On 3/4/14 6:09 PM, "Dan Smith" <dms at danplanet.com> wrote:

>> What I'd like to do next is work through a new proposal that includes
>> keeping both v2 and v3, but with a new added focus of minimizing the
>> cost.  This should include a path away from the dual code bases and to
>> something like the "v2.1" proposal.
>I think that the most we can hope for is consensus on _something_. So,
>the thing that I'm hoping would mostly satisfy the largest number of
>people is:
>- Leaving v2 and v3 as they are today in the tree, and with v3 still
>  marked experimental for the moment
>- We start on a v2 proxy to v3, with the first goal of fully
>  implementing the v2 API on top of v3, as judged by tempest
>- We define the criteria for removing the current v2 code and marking
>  the v3 code supported as:
> - The v2 proxy passes tempest
> - The v2 proxy has sign-off from some major deployers as something
>   they would be comfortable using in place of the existing v2 code
> - The v2 proxy seems to us to be lower maintenance and otherwise
>   preferable to either keeping both, breaking all our users, deleting
>   v3 entirely, etc
>- We keep this until we either come up with a proxy that works, or
>  decide that it's not worth the cost, etc.
>I think the list of benefits here are:
>- Gives the v3 code a chance to address some of the things we have
>  identified as lacking in both trees
>- Gives us a chance to determine if the proxy approach is reasonable or
>  a nightmare
>- Gives a clear go/no-go line in the sand that we can ask deployers to
>  critique or approve
>It doesn't address all of my concerns, but at the risk of just having
>the whole community split over this discussion, I think this is probably
>(hopefully?) something we can all get behind.
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list