On Thu, Aug 20, 2015 at 9:40 PM, Alex Xu <hejie...@intel.com> wrote:
> 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/ 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:

Yes, that much possible even if they not checking particular error
code but they could have checking for range of known error return for
that API.
Which makes me on side of microversion doc which say not to introduced
new error code without version bump.

>     …..
>
> 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
> , 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?

Not sure but more possibility is app checking range of returned error
code. If so then we should be ok but if they check particular error
code then you have much valid point to correct doc.

I was checking couple of patches for 500 correction which make me also
feel that we should fix all 500 thing in single microversion. Only
issue is we need to investigate well/complete before doing that. One
way can be keep adding finding somewhere and fix it at end of release
in single microversion.

>
> 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 <mrie...@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@IBMCN   Internet: jiche...@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-requ...@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
>
>  - 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks & Regards
Ghanshyam Mann

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to