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

[Alex Xu]

> 在 2015年8月21日，上午10:14，Alex Xu  写道：
> 
>> 
>> 在 2015年8月21日，上午3:09，Jay Pipes > > 写道：
>> 
>> On 08/20/2015 02:08 PM, melanie witt wrote:
>>> On Aug 20, 2015, at 5:40, Alex Xu >> > 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
 

  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
 


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/ 
> :
> 
> 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 
>> ?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

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

[GHANSHYAM MANN]

On Thu, Aug 20, 2015 at 3:33 AM, 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.

humm, actually m confused now whether we should consider changing
error code as backward incompatible or not. or its more broken in 2
part? 1 introduced new error code (500-> new error code) 2. changing
to existing error code and which one is backward incompatible?

IMO (considering most users/app checking existing/published error code
range) 1 one should be considered as backward incompatible.

>
> --
>
> 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



-- 
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

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

[GHANSHYAM MANN]

On Thu, Aug 20, 2015 at 9:40 PM, Alex Xu  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", "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  写道：
>
>
>
> 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
>
>
> 

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

[Alex Xu]

> 在 2015年8月21日，上午3:09，Jay Pipes  写道：
> 
> On 08/20/2015 02:08 PM, melanie witt wrote:
>> On Aug 20, 2015, at 5:40, Alex Xu  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.

So I changed the answer a little again in the 
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?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

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

[Jay Pipes]

On 08/20/2015 02:08 PM, melanie witt wrote:

On Aug 20, 2015, at 5:40, Alex Xu  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.

Best,
-jay

__
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

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

[melanie witt]

On Aug 20, 2015, at 5:40, Alex Xu  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.

-melanie (irc: melwitt)


[1] 
http://docs.openstack.org/developer/nova/api_microversion_dev.html#when-do-i-need-a-new-microversion
[2] 
http://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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

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

[Alex Xu]

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", "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
 

 , 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  写道：
> 
> 
> 
> 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 
> 
__

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

[John Garbutt]

On 19 August 2015 at 20:37, Matt Riedemann  wrote:
> 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.

I think the idea is we bump the microversion so the caller knows about
the new error code being possible.

Although I am tempted to say we make the change for all microversions,
to stop the nasty 500 error, which does reduce the value of the
version bump...

In the v2 API, we should probably just change the 500 to a better
return value as well, without and advertising. I think we used to
allow that.

Does that work?

John

__
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

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

[Matt Riedemann]

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

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

[Matt Riedemann]

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.


--

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

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

[Matt Riedemann]

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.


--

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-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?

[Chen CH Ji]

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