Open Stack

On 03/04/2014 08:14 AM, Daniel P. Berrange wrote:
> On Tue, Mar 04, 2014 at 07:49:03AM -0500, Sean Dague wrote:
>> So this thread is getting deep again, as I expect they all will, so I'm
>> just going to top post and take the ire for doing so.
>>
>> I also want to summarize what I've seen in the threads so far:
>>
>> v2 needed forever - if I do a sentiment analysis here looking at the
>> orgs people are coming from, most of this is currently coming from
>> Rackspace folks (publicly). There might be many reasons for this, one of
>> which is the fact that they've done a big transition in the near past
>> (between *not openstack* and Openstack), and felt that pain.
>> Understanding that pain is good.
>>
>> It is interesting that Phil actually brings up a completely different
>> issue from the HP cloud side, which is the amount of complaints they are
>> having to field about how terrible the v2 API is. HP has actually had an
>> OpenStack cloud public longer than Rackspace. So this feedback shouldn't
>> be lost.
>>
>> So I feel like while some deployers have expressed no interest in moving
>> forward on API, others can't get there soon enough.
>>
>> Which makes me think a lot about point 4. As has already been suggested
>> we could actually make v2 a proxy to v3. And just like with images and
>> volumes, it becomes frozen in Juno, and people that want more features
>> will move to the v3 API. Just like with other services.
> 
>> This requires internal cleanups as well. However it wouldn't shut down
>> future evolution of the interface.
>>
>> Nova really has 4 interfaces today
>>  * Nova v2 JSON
>>  * Nova v2 XML
>>  * Nova v3 JSON
>>  * EC2
>>
>> I feel like if we had to lose one to decrease maintenance cost, Nova v2
>> XML is the one to lose. And if we did, v2 on v3 isn't the craziest thing
>> in the world. It's not free, but neither is the backport.
> 
> A proxy of v2 onto v3 is appealing, but do we think we have good enough
> testing of v2 to ensure that any proxy impl is bug-for-bug compatible
> with the original native v2 implementation ? Avoiding breakage of client
> apps is to me the key reason for keeping v2 around, so we'd want very
> high confidence that any proxy impl is functionally identical with the
> orginal impl.

So because of Nova objects, Icehouse v2 isn't bug-for-bug compatible
with Havana v2 anyway. The API isn't isolated enough from the internals
at this point to actually provide those guaruntees in v2.

It doesn't seem unreasonable to me that v2 could be as good a guaruntee
as the one we have. A focus on increased coverage of the v2 API in
tempest would help. It would be great if the folks that are really
interested in keeping stable v2 (and ensuring we lock down the behavior)
would contribute there.

> If we want to proxy v2 onto v3, then by that same argument should we
> be proxying EC2 onto v3 as well.  ie Nova v3 JSON be the only supported
> API, and every thing else just be a proxy, potentially maintained out
> of tree from main nova codebase.

There are some fundamental issues around ids that make that problematic
(and that's only one of the concerns I know about). EC2 as a proxy (out
of tree) was discussed 3 cycles ago, and no one stepped up. And the
result has been no one working on EC2. So I'm actually really concerned
that if we don't reach a conclusion around Nova API that people are
excited about working on, we see the same core collapse there as we saw
on EC2.

	-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/20140304/276483a7/attachment.pgp>