Open Stack

> -----Original Message-----
> From: Alex Xu [mailto:xuhj at linux.vnet.ibm.com]
> Sent: Thursday, February 27, 2014 11:44 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Future of the Nova API
> 
> On 2014年02月26日 18:40, Thierry Carrez wrote:
> > Kenichi Oomichi wrote:
> >> Through v3 API development, we are making all v3 APIs return a BadRequest
> >> in this case. I think we cannot apply this kind of strict validation to
> >> running v2 API.
> >
> > We may need to differentiate between breaking the API and breaking
> > corner-case behavior. In one case you force everyone in the ecosystem to
> > adapt (the libraries, the end user code). In the other you only
> > (potentially) affect those that were not following the API correctly.
> >
> > So there may be a middle ground between "sticking with dirty V2 forever"
> > and "Go to V3 and accept a long V2 deprecation":
> 
> Let us find the middle ground, how about this:
> 
> 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.
> 
> 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.


Thanks
Ken'ichi Ohmichi