Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
On Thu, Aug 20, 2015 at 3:33 AM, Matt Riedemann mrie...@linux.vnet.ibm.com 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?
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.\nclass '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
Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
在 2015年8月21日，上午3:09，Jay Pipes 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 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/ 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?
在 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
Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
On 19 August 2015 at 20:37, Matt Riedemann mrie...@linux.vnet.ibm.com 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?
On Aug 20, 2015, at 5:40, Alex Xu 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. -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?
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.\nclass '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 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
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
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
Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
On 08/20/2015 02:08 PM, melanie witt wrote: On Aug 20, 2015, at 5:40, Alex Xu 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. 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?
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?
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
Re: [openstack-dev] [nova] should we combine a set of minor microversion bump needed fix into one microversoin bump?
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
