Open Stack

Let me wrote down what I’m analyse about this(I’m not good at this…and this spend another hour for me...):

When OverQuota isn’t catched by API layer, we will get response as below:

{"computeFault": {"message": "Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ <http://bugs.launchpad.net/nova/> and attach the Nova API log if possible.\n<class 'nova.exception.OverQuota'>", "code": 500}}

So user may wrote client like this:

if response.status == 500 and ‘OverQuota’ in response.message:
    …..

If we fix this to 403 without microversions, then in different openstack deployment we will have different return code for OverQuota.

From this doc http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n129 <http://git.openstack.org/cgit/openstack/nova/tree/doc/source/api_microversion_dev.rst#n129> , provide a way to avoid
bump microversion. The doc suggest turn it into existed return code. But looks like it still drop into the different openstack deployment case.
So can we remove this footnote?

If this analysis is correct, then we need new microverions.

For v2 API, I think we needn't fix it… If v2.1 fix with microverions, this fix can’t be back-port also, 500 bug is always part of old API contract.
If we want to make nova API consistent now, v2 API can follow this rule also, 500 is already part of contract of it.

Thanks,
Alex

> 在 2015年8月20日，上午3:37，Matt Riedemann <mriedem at linux.vnet.ibm.com> 写道：
> 
> 
> 
> On 8/19/2015 2:16 PM, Matt Riedemann wrote:
>> 
>> 
>> On 8/19/2015 1:33 PM, Matt Riedemann wrote:
>>> 
>>> 
>>> On 8/19/2015 12:18 PM, Chen CH Ji wrote:
>>>> In doing [1] [2], some suggestions raised that those kind of change need
>>>> microversion bump which is fine
>>>> however, another concern raised on whether we need combine a set of
>>>> those kind of changes (which may only change some error code) into one
>>>> bump ?
>>>> 
>>>> apparently there are pros and cons for doing so, combine makes API
>>>> version bump not that frequent for minor changes
>>>> but makes it hard to review and backport ... so any suggestions on how
>>>> to handle ? Thanks
>>>> 
>>>> 
>>>> [1]https://review.openstack.org/#/c/198753/
>>>> [2]https://review.openstack.org/#/c/173985/
>>>> 
>>>> Best Regards!
>>>> 
>>>> Kevin (Chen) Ji 纪 晨
>>>> 
>>>> Engineer, zVM Development, CSTL
>>>> Notes: Chen CH Ji/China/IBM at IBMCN   Internet: jichenjc at cn.ibm.com
>>>> Phone: +86-10-82454158
>>>> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
>>>> District, Beijing 100193, PRC
>>>> 
>>>> 
>>>> __________________________________________________________________________
>>>> 
>>>> 
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> 
>>> 
>>> I don't see why https://review.openstack.org/#/c/198753/ would require a
>>> microversion bump.  We've always allowed handling 500s and turning them
>>> into more appropriate error codes, like a 400 in this case.
>>> 
>>> As noted:
>>> 
>>> http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html
>>> 
>>> 
>>> 
>>> "Changing an error response code to be more accurate." is generally
>>> acceptable.
>>> 
>> 
>> https://review.openstack.org/#/c/173985/ doesn't require a version bump
>> for the same reasons, IMO.  If people are hung up on 400 vs 403 in that
>> change, just make it a 400, we do it both ways in the compute API.
>> 
> 
> I guess the problems are in the doc:
> 
> 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>
> 
>  - the list of status codes allowed for a particular request
> 
>    Example: an API previously could return 200, 400, 403, 404 and the
>    change would make the API now also be allowed to return 409.
> 
>  - changing a status code on a particular response
> 
>    Example: changing the return code of an API from 501 to 400.
> 
> So in the one change, just return 400.  In the service_get change where you want to return a 400 but it's only returning a 404 today, then I guess according to the doc you'd need a microversion bump. But what do we do about fixing that bug in the v2 API?  Do we not fix it?  Do we return 404 but v2.1 would return 400 with a microversion bump?  That's equally inconsistent and gross IMO.
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __________________________________________________________________________
> 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/20150820/a5b9c4c3/attachment.html>