On Tue, 4 Mar 2014 13:14:01 +0000 "Daniel P. Berrange" <berra...@redhat.com> 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 if 100% bug for bug compatibility is our top concern, then the last thing we want to do is to try to evolve the V2 API. Because we will end up breaking it accidentally. And it impacts what internal changes we can make because we've had problems with accidentally exposing internal implementation issues through the API. > 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. So I think this is a good long term goal (whether the proxying code is in our out of tree is up for debate). There are apparently issues with the EC2 needing something that our API doesn't expose, but perhaps it could. It just needs people who are willing to look at doing that work. Just as a random data point, when the devs who have been looking at implementing the google compute engine asked about this sort of thing on the mailing list, we suggested that they look at layering their API on top of the Nova API. And if IIRC they said that would be possible. Chris _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
