> 在 2015年8月21日，上午10:14，Alex Xu <hejie...@intel.com> 写道： > >> >> 在 2015年8月21日，上午3:09，Jay Pipes <jaypi...@gmail.com >> <mailto:jaypi...@gmail.com>> 写道： >> >> On 08/20/2015 02:08 PM, melanie witt wrote: >>> On Aug 20, 2015, at 5:40, Alex Xu <hejie...@intel.com >>> <mailto:hejie...@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-requ...@lists.openstack.org >> <mailto:openstack-dev-requ...@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>
__________________________________________________________________________ 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
