Open Stack

The current set of reviews on this change seems relevant to this debate:  https://review.openstack.org/#/c/43822/

In effect a fully working and tested change which makes the nova-net / neutron compatibility via the V2 API that little bit closer to being complete is being blocked because it's thought that by not having it people will be quicker to move to V3 instead.

Folks this is just madness - no one is going to jump to using V3 just because we don't fix minor things like this in V2,  they're just as likely to start jumping to something completely different "because that Openstack stuff is just too hard to work with".     User's don't think like developers, and you can't force them into a new API by deliberately keeping the old one bad - at least not if you want to keep them as users in the long term.

I can see an argument (maybe) for not adding lots of completely new features into V2 if V3 was already available in a stable form - but V2 already provides a nearly complete support for nova-net features on top of Neutron.    I fail to see what is wrong with continuing to improve that.

Phil

> -----Original Message-----
> From: Day, Phil
> Sent: 28 February 2014 11:07
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] Future of the Nova API
> 
> > -----Original Message-----
> > From: Chris Behrens [mailto:cbehrens at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev