[openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?

Alex Xu hejie.xu at intel.com
Fri Aug 21 02:25:51 UTC 2015


> 在 2015年8月21日,上午10:14,Alex Xu <hejie.xu at intel.com> 写道:
> 
>> 
>> 在 2015年8月21日,上午3:09,Jay Pipes <jaypipes at gmail.com <mailto:jaypipes at gmail.com>> 写道:
>> 
>> On 08/20/2015 02:08 PM, melanie witt wrote:
>>> On Aug 20, 2015, at 5:40, Alex Xu <hejie.xu at intel.com <mailto:hejie.xu at intel.com>> wrote:
>>> 
>>>> So user may wrote client like this:
>>>> 
>>>> if response.status == 500 and ‘OverQuota’ in response.message:
>>>>     …..
>>> 
>>> I thought we're not supporting that type of case. My understanding is that we should never be returning 500 and if we are, it's a bug fix to change it to an appropriate error status code without version bumps. I find it in the documentation [1][2] too.
>> 
>> Yup, you are correct.
> 
> Yea, from API-WG guideline, and from my understanding, I also agree to 500 isn’t expect error. 
> 
> Why I thinking of this, is because I want to explain how to deal with different deployment of openstack.
> 
> The one of goal for micro versions is to make our API consistent between different deployment and discoverable the change between the deployment.
> 
> Finally in this email I get answer for the different deployment question by make 500 as contract. yea, finally no one think this is right.
> 
> So, let me change another way to answer this question, and the baseline is 500 isn’t part of contract.
> 
> My answer is we did not have good API contract in the beginning(in the nova-spec).  For example, the bug we return 500 for overquota, if we have api ref or nova-spec said, we will return 403 for overquota, then the thing is very easy, we fix it with return 403 and no micro versions. But we didn’t have such doc or spec describe that, then we don’t know the API contract. But I think people we feel insane if we require such detail nova-spec again.

More explain for this part…avoid my poor English didn’t explain clearly. Let’s say if we have describe clearly in the nova-spec or api-ref to say 403 is available return code, then we needn’t detect what is available status code by checking the expected_error decorator https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/deferred_delete.py#L52 <https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/deferred_delete.py#L52>  Actually that decorator is part of bug, it isn’t part of contract.

If we have contract in the beginning, then we can answer this rule easily also http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n63 <http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n63>

So what I want to say, why we confuse on those, it because we didn’t have the initial contract...

> 
> So I changed the answer a little again in the https://review.openstack.org/#/c/215195/ <https://review.openstack.org/#/c/215195/>:
> 
> 500 isn't expect error. So user never should based on 500 error, and we won't guarantee anything on 500.
> There may have bug we should return 4** but we return 500. But if 4** is existed logic in the beginning of the API(Maybe we forget describe that in the nova-spec or api ref.), then we think the 4** already is part of API contract, we should fix it to match the contract, and it needn't new microversions.
> And we should back-port this fix. Operator should update their deployment to fix that bug.
> 
> Does this sounds make sense?
> 
> Thanks
> Alex
> 
>> 
>> Best,
>> -jay
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150821/8e0546ce/attachment.html>


More information about the OpenStack-dev mailing list