On 2014年02月26日 18:40, Thierry Carrez wrote:
Kenichi Oomichi wrote:
From: Christopher Yeoh [mailto:cbky...@gmail.com]
So the problem here is what we consider a "bug" becomes a feature from
a user of the API point of view. Eg they really shouldn't be passing
some data in a request, but its ignored and doesn't cause any issues
and the request ends up doing what they expect.
In addition, current v2 API behavior is not consistent when receiving
unexpected API parameters. Most v2 APIs ignore unexpected API parameters,
but some v2 APIs return a BadRequest response. For example, "update host"
API does it in this case by
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/hosts.py#L185
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.
We could make a V3 that doesn't break the API, only breaks behavior in
error cases due to its stronger input validation. A V3 that shouldn't
break code that was following the API, nor require heavy library
changes. It's still a major API bump because behavior may change and
some end users will be screwed in the process, but damage is more
limited, so V2 could go away after a shorter deprecation period.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
