Open Stack

On 25 February 2014 09:44, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> On Mon, 24 Feb 2014 21:15:30 -0500
> Russell Bryant <rbryant at redhat.com> wrote:
>
>> CC'ing the openstack-operators mailing list to get a wider set of
>> feedback on this question.
>>
>> On 02/24/2014 05:26 PM, Christopher Yeoh wrote:
>> >> 1) Continue as we have been, and plan to release v3 once we have a
>> >> compelling enough feature set.
>> >
>> > So I think we should release in Juno even if its only with tasks and
>> > nova-network added. Because this allows new users to start using the
>> > API immediately rather than having to code against V2 (with its
>> > extra barriers to use) and then take the hit to upgrade later.
>>
>> OK, let's go a bit further with the case of marking the v3 API stable
>> in Juno.  If we did that, what is a reasonable timeframe of v2 being
>> deprecated before it could be removed?
>
> So this might a lot more complicated to answer, but I'd also be
> interested in how much of the v2 API people actually use in practice
> (both users and deployers). I suspect there's bits that are either
> never or rarely used that we could perhaps deprecate earlier which
> would reduce the test/maintenance load. quota-classes is an example
> which has been in since early 2012 and we only recently realised that it
> doesn't actually do anything useful and so removed it.

I think this is the big question.

I could see a chance of removing v2 after two years, maybe three
years. But two years is a long time to have the current two API code
bases, that are very similar, but a little bit different.

I think we need to find an alternative way to support the new and old
formats, like Accepts Headers, and retro-fitting a version to
extensions so we can easily advertise new attributes, to those parsers
that will break when they encounter those kinds of things.

Now I am tempted to say we morph the V3 code to also produce the V2
responses. And change the v3 API, so thats easier to do, and easier
for clients to move (like don't change URLs unless we really have to).
I know the risk for screwing that up is enormous, but maybe that makes
the most sense?

John