Open Stack

2014-02-25 19:48 GMT+09:00 Thierry Carrez <thierry at openstack.org>:
> Sean Dague wrote:
>> So, that begs a new approach. Because I think at this point even if we
>> did put out Nova v3, there can never be a v4. It's too much, too big,
>> and doesn't fit in the incremental nature of the project. So whatever
>> gets decided about v3, the thing that's important to me is a sane way to
>> be able to add backwards compatible changes (which we actually don't
>> have today, and I don't think any other service in OpenStack does
>> either), as well a mechanism for deprecating parts of the API. With some
>> future decision about whether removing them makes sense.
>
> I agree with Sean. Whatever solution we pick, we need to make sure it's
> solid enough that it can handle further evolutions of the Nova API
> without repeating this dilemma tomorrow. V2 or V3, we would stick to it
> for the foreseeable future.
>
> Between the cleanup of the API, the drop of XML support, and including a
> sane mechanism for supporting further changes without major bumps of the
> API, we may have enough to technically justify v3 at this point. However
> from a user standpoint, given the surface of the API, it can't be
> deprecated fast -- so this ideal solution only works in a world with
> infinite maintenance resources.
>
> Keeping V2 forever is more like a trade-off, taking into account the
> available maintenance resources and the reality of Nova's API huge
> surface. It's less satisfying technically, especially if you're deeply
> aware of the API incoherent bits, and the prospect of living with some
> of this incoherence forever is not really appealing.

What is the maintenance cost for keeping both APIs?
I think Chris and his team have already paid most part of it, the
works for porting
the existing v2 APIs to v3 APIs is almost done.
So I'd like to clarify the maintenance cost we are discussing.

If the cost means that we should implement both API methods when creating a
new API, how about implementing internal proxy from v2 to v3 API?
When creating a new API, it is enough to implement API method for v3 API. and
when receiving a v2 request, Nova translates it to v3 API.
The request styles(url, body) of v2 and v3 are different and this idea makes new
v2 APIs v3 style. but now v2 API has already a lot of inconsistencies.
so it does not seem so big problem.


>From the viewpoint of OpenStack interoperability also, I believe we
need a new API.
Many v2 API parameters are not validated. If implementing strict
validation for v2 API,
incompatibility issues happen. That is why we are implementing input
validation for
v3 API. If staying v2 API forever, we should have this kind of problem forever.
v2 API is fragile now. So the interoperability should depend on v2
API, that seems
sandbox.. (I know that it is a little overstatement, but we have found
a lot of this kind
of problem already..)


Thanks
Ken'ichi Ohmichi