Open Stack

+1 

If we don't recognize that v2 is going to be around for a long time, have
some growth/require support we are kidding ourselves.  Establishing a
timeline to deprecation prior to release of v3 is not the right decision
point.  We should determine if v3 is ready for primetime, be willing to
support both ongoing, and ready to bring information to the table to
determine the right timeline for deprecation in a future release (a
timeline for a timeline).

Christopher

On 2/28/14 8:48 AM, "Day, Phil" <philip.day at hp.com> wrote:

>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
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev