> -----Original Message----- > From: Chris Behrens [mailto:cbehr...@codestud.com] > Sent: 26 February 2014 22:05 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova] Future of the Nova API > > > This thread is many messages deep now and I'm busy with a conference this > week, but I wanted to carry over my opinion from the other "v3 API in > Icehouse" thread and add a little to it. > > Bumping versions is painful. v2 is going to need to live for "a long time" to > create the least amount of pain. I would think that at least anyone running a > decent sized Public Cloud would agree, if not anyone just running any sort of > decent sized cloud. I don't think there's a compelling enough reason to > deprecate v2 and cause havoc with what we currently have in v3. I'd like us > to spend more time on the proposed "tasks" changes. And I think we need > more time to figure out if we're doing versioning in the correct way. If we've > got it wrong, a v3 doesn't fix the problem and we'll just be causing more > havoc with a v4. > > - Chris > Like Chris I'm struggling to keep up with this thread, but of all the various messages I've read this is the one that resonates most with me.
My perception of the V3 API improvements (in order to importance to me): i) The ability to version individual extensions Crazy that small improvements can't be introduced without having to create a new extension, when often the extension really does nothing more that indicate that some other part of the API code has changed. ii) The opportunity to get the proper separation between Compute and Network APIs Being (I think) one of the few clouds that provides both the Nova and Neutron API this is a major source of confusion and hence support calls. iii) The introduction of the task model I like the idea of tasks, and think it will be a much easier way for users to interact with the system. Not convinced that it couldn't co-exist in V2 thought rather than having to co-exist as V2 and V3 iv)Clean-up of a whole bunch of minor irritations / inconsistencies There are lots of things that are really messy (inconsistent error codes, aspects of core that are linked to just Xen, etc, etc). They annoy people the first time they hit them, then the code around them and move on. Probably I've had more hate mail from people writing language bindings than application developers (who tend to be abstracted from this by the clients) Phil _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
