Open Stack

On 03/04/2014 10:44 PM, Christopher Yeoh wrote:
> On Tue, 04 Mar 2014 16:09:21 -0800
> 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.
>>
>> Thoughts?

I think this is a solid plan to move forward on, and gives the proxy
idea a chance to prove itself.

> 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 :-)

100% agreed. I *highly* encourage any groups that are CDing OpenStack to
get engaged in Tempest, because that's our upstream mechanism for
blocking breaking code. Enhancements on the Nova v2 testing will ensure
that v2 surface does not change in ways that are important to people.

> - 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.

> - I'm not sure how this affects how we approach the tasks work. Will
>   need to think about that more.
> 
> But this plan is certainly something I'm happy to support.

Agreed. If we are committing to this route, I would like to see both a
POC on the proxy, and early findings at Atlanta, so we can figure out if
this is crazy or sane, and really define the exit criteria. The point of
giving the proxy idea a chance, is the assumption that it's actually a
less overhead way to evolve our API, and still keep backwards compat.

But if we don't have some good indications of that being true in
Atlanta, then I don't want us fully committing to a long slog into the
unknown here.

So work is cut out for folks that want to head down this path. But I
think the early data in Atlanta will be incredibly valuable in figuring
out how we move forward.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140305/33ef7bfb/attachment.pgp>