Open Stack

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.

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|