Open Stack

On Thu, 27 Feb 2014 03:38:25 +0000
Kenichi Oomichi <oomichi at mxs.nes.nec.co.jp> wrote:
> > 
> > v3: This is the total new api. it's with CamelCase fixing, stronger
> > input vaildation, api policy checks, and task api.
> > 
> > v2.1: This is based on v3, we transform the v2 request into v3
> > request(then they are share same codebase). This api is without
> > CamelCase fixing. And it get new thing from v3: stronger input
> > vaildation, api policy checks, task api. We are keeping this api for
> > long time. V2.1 didn't break the api. This api only affect those
> > that were not following v2 api correctly.

So the only thing I don't think we can really do for v2.1 is tasks.
Because the API we want is inherently backwards incompatible with v2.
We want to change what quite a few methods return.

Also there would be no XML support for v2.1 but its now marked as
deprecated so that is perhaps not an issue for the timeframe we are
discussing.

> > 
> > v2: just go away after a shorter deprecation period.
> > 
> > So v3 and v2.1 based on same code, this is reduce the cost of
> > maintenance. v2 is keeping for short time, give people a chance to
> > move to v2.1 or v3.
> > And v2.1 didn't break the api, and it's more easy for maintenance.
> 
> I also have the similar idea.
> 
> The above v2.1 idea does not break the existing API request body
> format, and also we need to translate v3 to v2 for API response.
> According to https://wiki.openstack.org/wiki/NovaAPIv2tov3 , we have
> changed API response(response code, response body) also in v3 API. So
> some response translations also seem necessary. I think the scope of
> the translations should contain successful access only, and it should
> not contain error access because of low maintenance cost, strong
> input vaildation, and errors due to client-side.
> 

Yep so we would also not be fixing success codes which are incorrect.
Error codes would change, but we do that in our 'stable' api anyway.

Yes so it comes back to an earlier suggestion I made around using
decorators for the v3 API that emulate v2 which would allow us to
mangle both the input and output. But in this case we don't need to
worry about the quirks because we're saying that sort of breakage is ok
(so risk is a lot lower, and verification much easier).  

I think the critical question here is how fast can we deprecate V2
once V2.1 is released? Is that any faster than a V2 to V3 deprecation
or do we have to support for V2 anyway for say 3 years?

Chris