[openstack-dev] [nova] Future of the Nova API

Alex Xu xuhj at linux.vnet.ibm.com
Tue Feb 25 14:11:44 UTC 2014


On 2014年02月25日 21:17, Ken'ichi Ohmichi wrote:
> 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.
I want to ask this question too. What is the maintenance cost?
When we release v3 api, we will freeze v2 api. So we won't add any new 
API into v2,
So is that mean the maintenance cost is much less after v2 api froze?
What I know is we should keep compute-api keep back-compatibility with 
v2 api. What
else except that?

>
> >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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>




More information about the OpenStack-dev mailing list