Re: [openstack-dev] [nova][api] New micro-version needed for api bug fix or not?
On 4 June 2015 at 10:40, Jens Rosenboom j.rosenb...@x-ion.de wrote: 2015-06-03 14:25 GMT+02:00 John Garbutt j...@johngarbutt.com: On 3 June 2015 at 12:52, Jay Pipes jaypi...@gmail.com wrote: On 06/03/2015 02:34 AM, Chris Friesen wrote: On 06/03/2015 12:16 AM, Jens Rosenboom wrote: I'm wondering though whether the current API behaviour here should be changed more generally. Is there a plausible reason to silently discard options that are not allowed for non-admins? For me it would make more sense to return an error in that case. If we're bumping the microversion anyways, I'd be in favor of having that throw an error rather than silently ignore options. You could maybe even have a helpful those options require admin privileges error message that gets displayed to the user. ++ +1 We must keep adding this sort of validation as we evolve v2.1 This is a one of the big changes in the default behaviour since v2.0, validate input, and make things discoverable, rather than silently fail. O.k., but can we agree that this will be a second step which can be handled after the current bugfix-microversion-spec? We can do this in a separate bug fix if you prefer. IIUC we cannot change the behaviour for the old API anyway, so this would only affect the remaining admin-only options. Stopping things silently fail, is exactly the kind of change I want to see us do more of in v2.1. I see it as a follow up on all the JSON schema validation we have added. Thanks, 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][api] New micro-version needed for api bug fix or not?
2015-06-03 14:25 GMT+02:00 John Garbutt j...@johngarbutt.com: On 3 June 2015 at 12:52, Jay Pipes jaypi...@gmail.com wrote: On 06/03/2015 02:34 AM, Chris Friesen wrote: On 06/03/2015 12:16 AM, Jens Rosenboom wrote: I'm wondering though whether the current API behaviour here should be changed more generally. Is there a plausible reason to silently discard options that are not allowed for non-admins? For me it would make more sense to return an error in that case. If we're bumping the microversion anyways, I'd be in favor of having that throw an error rather than silently ignore options. You could maybe even have a helpful those options require admin privileges error message that gets displayed to the user. ++ +1 We must keep adding this sort of validation as we evolve v2.1 This is a one of the big changes in the default behaviour since v2.0, validate input, and make things discoverable, rather than silently fail. O.k., but can we agree that this will be a second step which can be handled after the current bugfix-microversion-spec? IIUC we cannot change the behaviour for the old API anyway, so this would only affect the remaining admin-only options. __ 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][api] New micro-version needed for api bug fix or not?
On 06/03/2015 02:34 AM, Chris Friesen wrote: On 06/03/2015 12:16 AM, Jens Rosenboom wrote: I'm wondering though whether the current API behaviour here should be changed more generally. Is there a plausible reason to silently discard options that are not allowed for non-admins? For me it would make more sense to return an error in that case. If we're bumping the microversion anyways, I'd be in favor of having that throw an error rather than silently ignore options. You could maybe even have a helpful those options require admin privileges error message that gets displayed to the user. ++ -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][api] New micro-version needed for api bug fix or not?
2015-06-01 13:40 GMT+02:00 John Garbutt j...@johngarbutt.com: On 31 May 2015 at 14:15, Xu, Hejie hejie...@intel.com wrote: Replied in line with prefix [alex] -Original Message- ... 2) We also agreed that all micro version bumps need a spec, to help avoid is adding more bad things to the API as we try and move forward. This is heavy weight. In time, we might find certain good patterns where we want to relax that restriction, but we haven't done enough changes to agree on those patterns yet. This will mean we are moving a bit slower at first, but it feels like the right trade off against releasing (i.e. something that lands in any commit on master) an API with a massive bug we have to support for a long time. [alex]: For this case, do we need register a blueprint for it? Maybe we just reference the bug in the nova-spec is enough. Right now, we have said everything needs a spec. They can be a very, very, short spec. It might become clear there are some places we should skip this, as clear patterns emerge. But as we consider every commit a release, this is very dangerous, hence the caution we are applying here. So I have now submitted a spec proposal at https://review.openstack.org/187835 and added the microversion to https://review.openstack.org/179569. I'm wondering though whether the current API behaviour here should be changed more generally. Is there a plausible reason to silently discard options that are not allowed for non-admins? For me it would make more sense to return an error in that case. __ 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][api] New micro-version needed for api bug fix or not?
-Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] Sent: Monday, June 1, 2015 7:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug fix or not? On 31 May 2015 at 14:15, Xu, Hejie hejie...@intel.com wrote: Replied in line with prefix [alex] -Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] 1) We agreed changing a 500 error to an existing error (or making it succeed in the usual way) is a change that doesn't need a version bump, its a bug fix. [alex] from the etherpad https://etherpad.openstack.org/p/YVR-nova-contributor-meetup it said fix 500 for existed error can be without bump version. If it is new type of error code, that would need bump. +1 [alex] But I'm not quite understand this one. There maybe some new functionality add to API, then there are some exception forget to catching, then server return 500. After we found this error, I didn't found out the reason we should bump version. Basically, we are saying we need to bump the version when the API user has a new error code they need to understand. Since 500 is never an expected result, its fine to move those error cases to some other error case the API user already understands. If there is a new error code required, that means there os something new for the client to understand, so we need to bump the version, so we tell clients when that new error code will be available. At least thats how I remember the discussion. I only thought out the new error code only can be introduced by some new functionality or some bug fix for restricting the request checks. In those case, there should already have one version bump for it. The 500 error is generated by that version, we needn't bump version again, just need fix the 500 in the Version we introduced. 2) We also agreed that all micro version bumps need a spec, to help avoid is adding more bad things to the API as we try and move forward. This is heavy weight. In time, we might find certain good patterns where we want to relax that restriction, but we haven't done enough changes to agree on those patterns yet. This will mean we are moving a bit slower at first, but it feels like the right trade off against releasing (i.e. something that lands in any commit on master) an API with a massive bug we have to support for a long time. [alex]: For this case, do we need register a blueprint for it? Maybe we just reference the bug in the nova-spec is enough. Right now, we have said everything needs a spec. They can be a very, very, short spec. It might become clear there are some places we should skip this, as clear patterns emerge. But as we consider every commit a release, this is very dangerous, hence the caution we are applying here. Now when it comes to your change. It is a bug in the default policy. Sadly this policy is also quite hard wired to admin vs non-admin. We still need work to make policy more discoverable, so I don't think we need to make this any more discoverable as such. [alex]: This isn't controlled by policy currently, or your think those query parameter should controlled by policy? It is controlled by context.is_admin. I am thinking all of those should really become resource specific policy. Mostly because many larger deployers have various levels of admin. Thanks, 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 __ 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][api] New micro-version needed for api bug fix or not?
On 06/03/2015 12:16 AM, Jens Rosenboom wrote: I'm wondering though whether the current API behaviour here should be changed more generally. Is there a plausible reason to silently discard options that are not allowed for non-admins? For me it would make more sense to return an error in that case. If we're bumping the microversion anyways, I'd be in favor of having that throw an error rather than silently ignore options. You could maybe even have a helpful those options require admin privileges error message that gets displayed to the user. Chris __ 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][api] New micro-version needed for api bug fix or not?
-Original Message- From: Jens Rosenboom [mailto:j.rosenb...@x-ion.de] Sent: Wednesday, June 3, 2015 2:17 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug fix or not? 2015-06-01 13:40 GMT+02:00 John Garbutt j...@johngarbutt.com: On 31 May 2015 at 14:15, Xu, Hejie hejie...@intel.com wrote: Replied in line with prefix [alex] -Original Message- ... 2) We also agreed that all micro version bumps need a spec, to help avoid is adding more bad things to the API as we try and move forward. This is heavy weight. In time, we might find certain good patterns where we want to relax that restriction, but we haven't done enough changes to agree on those patterns yet. This will mean we are moving a bit slower at first, but it feels like the right trade off against releasing (i.e. something that lands in any commit on master) an API with a massive bug we have to support for a long time. [alex]: For this case, do we need register a blueprint for it? Maybe we just reference the bug in the nova-spec is enough. Right now, we have said everything needs a spec. They can be a very, very, short spec. It might become clear there are some places we should skip this, as clear patterns emerge. But as we consider every commit a release, this is very dangerous, hence the caution we are applying here. So I have now submitted a spec proposal at https://review.openstack.org/187835 and added the microversion to https://review.openstack.org/179569. I'm wondering though whether the current API behaviour here should be changed more generally. Is there a plausible reason to silently discard options that are not allowed for non-admins? For me it would make more sense to return an error in that case. Most of web server ignore the extra query string. If this isn't enable for current user, then it is non-exist for current user. Does make sense? This should be something we doc in the api-wg guideline. __ 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][api] New micro-version needed for api bug fix or not?
-Original Message- From: Xu, Hejie [mailto:hejie...@intel.com] Sent: Wednesday, June 3, 2015 3:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug fix or not? -Original Message- From: Jens Rosenboom [mailto:j.rosenb...@x-ion.de] Sent: Wednesday, June 3, 2015 2:17 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug fix or not? 2015-06-01 13:40 GMT+02:00 John Garbutt j...@johngarbutt.com: On 31 May 2015 at 14:15, Xu, Hejie hejie...@intel.com wrote: Replied in line with prefix [alex] -Original Message- ... 2) We also agreed that all micro version bumps need a spec, to help avoid is adding more bad things to the API as we try and move forward. This is heavy weight. In time, we might find certain good patterns where we want to relax that restriction, but we haven't done enough changes to agree on those patterns yet. This will mean we are moving a bit slower at first, but it feels like the right trade off against releasing (i.e. something that lands in any commit on master) an API with a massive bug we have to support for a long time. [alex]: For this case, do we need register a blueprint for it? Maybe we just reference the bug in the nova-spec is enough. Right now, we have said everything needs a spec. They can be a very, very, short spec. It might become clear there are some places we should skip this, as clear patterns emerge. But as we consider every commit a release, this is very dangerous, hence the caution we are applying here. So I have now submitted a spec proposal at https://review.openstack.org/187835 and added the microversion to https://review.openstack.org/179569. I'm wondering though whether the current API behaviour here should be changed more generally. Is there a plausible reason to silently discard options that are not allowed for non-admins? For me it would make more sense to return an error in that case. Most of web server ignore the extra query string. If this isn't enable for current user, then it is non-exist for current user. Does make sense? This should be something we doc in the api-wg guideline. Just send out https://review.openstack.org/187903 __ 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 __ 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][api] New micro-version needed for api bug fix or not?
On 3 June 2015 at 12:52, Jay Pipes jaypi...@gmail.com wrote: On 06/03/2015 02:34 AM, Chris Friesen wrote: On 06/03/2015 12:16 AM, Jens Rosenboom wrote: I'm wondering though whether the current API behaviour here should be changed more generally. Is there a plausible reason to silently discard options that are not allowed for non-admins? For me it would make more sense to return an error in that case. If we're bumping the microversion anyways, I'd be in favor of having that throw an error rather than silently ignore options. You could maybe even have a helpful those options require admin privileges error message that gets displayed to the user. ++ +1 We must keep adding this sort of validation as we evolve v2.1 This is a one of the big changes in the default behaviour since v2.0, validate input, and make things discoverable, rather than silently fail. Thanks, 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][api] New micro-version needed for api bug fix or not?
On 31 May 2015 at 14:15, Xu, Hejie hejie...@intel.com wrote: Replied in line with prefix [alex] -Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] 1) We agreed changing a 500 error to an existing error (or making it succeed in the usual way) is a change that doesn't need a version bump, its a bug fix. [alex] from the etherpad https://etherpad.openstack.org/p/YVR-nova-contributor-meetup it said fix 500 for existed error can be without bump version. If it is new type of error code, that would need bump. +1 [alex] But I'm not quite understand this one. There maybe some new functionality add to API, then there are some exception forget to catching, then server return 500. After we found this error, I didn't found out the reason we should bump version. Basically, we are saying we need to bump the version when the API user has a new error code they need to understand. Since 500 is never an expected result, its fine to move those error cases to some other error case the API user already understands. If there is a new error code required, that means there os something new for the client to understand, so we need to bump the version, so we tell clients when that new error code will be available. At least thats how I remember the discussion. 2) We also agreed that all micro version bumps need a spec, to help avoid is adding more bad things to the API as we try and move forward. This is heavy weight. In time, we might find certain good patterns where we want to relax that restriction, but we haven't done enough changes to agree on those patterns yet. This will mean we are moving a bit slower at first, but it feels like the right trade off against releasing (i.e. something that lands in any commit on master) an API with a massive bug we have to support for a long time. [alex]: For this case, do we need register a blueprint for it? Maybe we just reference the bug in the nova-spec is enough. Right now, we have said everything needs a spec. They can be a very, very, short spec. It might become clear there are some places we should skip this, as clear patterns emerge. But as we consider every commit a release, this is very dangerous, hence the caution we are applying here. Now when it comes to your change. It is a bug in the default policy. Sadly this policy is also quite hard wired to admin vs non-admin. We still need work to make policy more discoverable, so I don't think we need to make this any more discoverable as such. [alex]: This isn't controlled by policy currently, or your think those query parameter should controlled by policy? It is controlled by context.is_admin. I am thinking all of those should really become resource specific policy. Mostly because many larger deployers have various levels of admin. Thanks, 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][api] New micro-version needed for api bug fix or not?
On 29 May 2015 at 19:58, Jay Pipes jaypi...@gmail.com wrote: On 05/29/2015 05:04 AM, John Garbutt wrote: On 29 May 2015 at 09:00, Sahid Orentino Ferdjaoui sahid.ferdja...@redhat.com wrote: On Fri, May 29, 2015 at 08:47:01AM +0200, Jens Rosenboom wrote: As the discussion in https://review.openstack.org/179569 still continues about whether this is just a bug fix, or an API change that will need a new micro version, maybe it makes sense to take this issue over here to the ML. Changing version of the API probably makes sense also for bug if it changes the behavior of a command/option to something backward incompatible. I do not believe it is the case for your change. My personal opinion is undecided, I can see either option as being valid, but maybe after having this open bug for four weeks now we can come to some conclusion either way. Apologies for this, we are still trying to evolve the rules for when to bump the API micro versions, there will be some pain while we work that out :( From the summit discussion, I think got three things roughly agreed (although we have not yet got them written up into a devref document, to make the formal agreement, and we need to do that ASAP): 1) We agreed changing a 500 error to an existing error (or making it succeed in the usual way) is a change that doesn't need a version bump, its a bug fix. 2) We also agreed that all micro version bumps need a spec, to help avoid is adding more bad things to the API as we try and move forward. This is heavy weight. In time, we might find certain good patterns where we want to relax that restriction, but we haven't done enough changes to agree on those patterns yet. This will mean we are moving a bit slower at first, but it feels like the right trade off against releasing (i.e. something that lands in any commit on master) an API with a massive bug we have to support for a long time. 3) Discuss other cases as they came up, and evolve the plans based on the examples that come up, with a focus on bumping the version being (almost) free, and useful for clients to work out what has changed. Is that how everyone else remembers that discussion? Yes. Now when it comes to your change. It is a bug in the default policy. Sadly this policy is also quite hard wired to admin vs non-admin. We still need work to make policy more discoverable, so I don't think we need to make this any more discoverable as such. Having said all that, we probably need to look at this case more carefully, after your patch has merged, and work out how this should work now we assuming strong validation, and granular policy, etc. Actually, after reading the IRC conversation between Dims and Sean, I believe Sean is right to want a microversion bump for this patch. If two clouds are deployed, one with this patch and another without, a client issuing commands to both will have no idea whether the ip6 filter will be considered or not. Having a microversion increment in the patch would allow clients to request behaviour they want (the ip6 filter). Ah, true. If the cloud that ignored the ip6 filter actually had errored out when given an ip6 filter, it would be very different. But you are right, it silently ignores the param, which can lead to confusion, so its probably best to bump the version. Thanks, 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][api] New micro-version needed for api bug fix or not?
Replied in line with prefix [alex] -Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] Sent: Friday, May 29, 2015 8:05 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug fix or not? On 29 May 2015 at 09:00, Sahid Orentino Ferdjaoui sahid.ferdja...@redhat.com wrote: On Fri, May 29, 2015 at 08:47:01AM +0200, Jens Rosenboom wrote: As the discussion in https://review.openstack.org/179569 still continues about whether this is just a bug fix, or an API change that will need a new micro version, maybe it makes sense to take this issue over here to the ML. Changing version of the API probably makes sense also for bug if it changes the behavior of a command/option to something backward incompatible. I do not believe it is the case for your change. My personal opinion is undecided, I can see either option as being valid, but maybe after having this open bug for four weeks now we can come to some conclusion either way. Apologies for this, we are still trying to evolve the rules for when to bump the API micro versions, there will be some pain while we work that out :( From the summit discussion, I think got three things roughly agreed (although we have not yet got them written up into a devref document, to make the formal agreement, and we need to do that ASAP): 1) We agreed changing a 500 error to an existing error (or making it succeed in the usual way) is a change that doesn't need a version bump, its a bug fix. [alex] from the etherpad https://etherpad.openstack.org/p/YVR-nova-contributor-meetup it said fix 500 for existed error can be without bump version. If it is new type of error code, that would need bump. But I'm not quite understand this one. There maybe some new functionality add to API, then there are some exception forget to catching, then server return 500. After we found this error, I didn't found out the reason we should bump version. 2) We also agreed that all micro version bumps need a spec, to help avoid is adding more bad things to the API as we try and move forward. This is heavy weight. In time, we might find certain good patterns where we want to relax that restriction, but we haven't done enough changes to agree on those patterns yet. This will mean we are moving a bit slower at first, but it feels like the right trade off against releasing (i.e. something that lands in any commit on master) an API with a massive bug we have to support for a long time. [alex]: For this case, do we need register a blueprint for it? Maybe we just reference the bug in the nova-spec is enough. 3) Discuss other cases as they came up, and evolve the plans based on the examples that come up, with a focus on bumping the version being (almost) free, and useful for clients to work out what has changed. Is that how everyone else remembers that discussion? Now when it comes to your change. It is a bug in the default policy. Sadly this policy is also quite hard wired to admin vs non-admin. We still need work to make policy more discoverable, so I don't think we need to make this any more discoverable as such. [alex]: This isn't controlled by policy currently, or your think those query parameter should controlled by policy? Having said all that, we probably need to look at this case more carefully, after your patch has merged, and work out how this should work now we assuming strong validation, and granular policy, etc. But maybe there is something massive here? Thanks, 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 __ 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][api] New micro-version needed for api bug fix or not?
I also learn that from Sean! -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: Saturday, May 30, 2015 2:58 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug fix or not? On 05/29/2015 05:04 AM, John Garbutt wrote: On 29 May 2015 at 09:00, Sahid Orentino Ferdjaoui sahid.ferdja...@redhat.com wrote: On Fri, May 29, 2015 at 08:47:01AM +0200, Jens Rosenboom wrote: As the discussion in https://review.openstack.org/179569 still continues about whether this is just a bug fix, or an API change that will need a new micro version, maybe it makes sense to take this issue over here to the ML. Changing version of the API probably makes sense also for bug if it changes the behavior of a command/option to something backward incompatible. I do not believe it is the case for your change. My personal opinion is undecided, I can see either option as being valid, but maybe after having this open bug for four weeks now we can come to some conclusion either way. Apologies for this, we are still trying to evolve the rules for when to bump the API micro versions, there will be some pain while we work that out :( From the summit discussion, I think got three things roughly agreed (although we have not yet got them written up into a devref document, to make the formal agreement, and we need to do that ASAP): 1) We agreed changing a 500 error to an existing error (or making it succeed in the usual way) is a change that doesn't need a version bump, its a bug fix. 2) We also agreed that all micro version bumps need a spec, to help avoid is adding more bad things to the API as we try and move forward. This is heavy weight. In time, we might find certain good patterns where we want to relax that restriction, but we haven't done enough changes to agree on those patterns yet. This will mean we are moving a bit slower at first, but it feels like the right trade off against releasing (i.e. something that lands in any commit on master) an API with a massive bug we have to support for a long time. 3) Discuss other cases as they came up, and evolve the plans based on the examples that come up, with a focus on bumping the version being (almost) free, and useful for clients to work out what has changed. Is that how everyone else remembers that discussion? Yes. Now when it comes to your change. It is a bug in the default policy. Sadly this policy is also quite hard wired to admin vs non-admin. We still need work to make policy more discoverable, so I don't think we need to make this any more discoverable as such. Having said all that, we probably need to look at this case more carefully, after your patch has merged, and work out how this should work now we assuming strong validation, and granular policy, etc. Actually, after reading the IRC conversation between Dims and Sean, I believe Sean is right to want a microversion bump for this patch. If two clouds are deployed, one with this patch and another without, a client issuing commands to both will have no idea whether the ip6 filter will be considered or not. Having a microversion increment in the patch would allow clients to request behaviour they want (the ip6 filter). Best, -jay But maybe there is something massive here? Thanks, 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 __ 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][api] New micro-version needed for api bug fix or not?
On Fri, May 29, 2015 at 08:47:01AM +0200, Jens Rosenboom wrote: As the discussion in https://review.openstack.org/179569 still continues about whether this is just a bug fix, or an API change that will need a new micro version, maybe it makes sense to take this issue over here to the ML. Changing version of the API probably makes sense also for bug if it changes the behavior of a command/option to something backward incompatible. I do not believe it is the case for your change. My personal opinion is undecided, I can see either option as being valid, but maybe after having this open bug for four weeks now we can come to some conclusion either way. Yours, Jens __ 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
[openstack-dev] [nova][api] New micro-version needed for api bug fix or not?
As the discussion in https://review.openstack.org/179569 still continues about whether this is just a bug fix, or an API change that will need a new micro version, maybe it makes sense to take this issue over here to the ML. My personal opinion is undecided, I can see either option as being valid, but maybe after having this open bug for four weeks now we can come to some conclusion either way. Yours, Jens __ 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][api] New micro-version needed for api bug fix or not?
On 29 May 2015 at 09:00, Sahid Orentino Ferdjaoui sahid.ferdja...@redhat.com wrote: On Fri, May 29, 2015 at 08:47:01AM +0200, Jens Rosenboom wrote: As the discussion in https://review.openstack.org/179569 still continues about whether this is just a bug fix, or an API change that will need a new micro version, maybe it makes sense to take this issue over here to the ML. Changing version of the API probably makes sense also for bug if it changes the behavior of a command/option to something backward incompatible. I do not believe it is the case for your change. My personal opinion is undecided, I can see either option as being valid, but maybe after having this open bug for four weeks now we can come to some conclusion either way. Apologies for this, we are still trying to evolve the rules for when to bump the API micro versions, there will be some pain while we work that out :( From the summit discussion, I think got three things roughly agreed (although we have not yet got them written up into a devref document, to make the formal agreement, and we need to do that ASAP): 1) We agreed changing a 500 error to an existing error (or making it succeed in the usual way) is a change that doesn't need a version bump, its a bug fix. 2) We also agreed that all micro version bumps need a spec, to help avoid is adding more bad things to the API as we try and move forward. This is heavy weight. In time, we might find certain good patterns where we want to relax that restriction, but we haven't done enough changes to agree on those patterns yet. This will mean we are moving a bit slower at first, but it feels like the right trade off against releasing (i.e. something that lands in any commit on master) an API with a massive bug we have to support for a long time. 3) Discuss other cases as they came up, and evolve the plans based on the examples that come up, with a focus on bumping the version being (almost) free, and useful for clients to work out what has changed. Is that how everyone else remembers that discussion? Now when it comes to your change. It is a bug in the default policy. Sadly this policy is also quite hard wired to admin vs non-admin. We still need work to make policy more discoverable, so I don't think we need to make this any more discoverable as such. Having said all that, we probably need to look at this case more carefully, after your patch has merged, and work out how this should work now we assuming strong validation, and granular policy, etc. But maybe there is something massive here? Thanks, 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][api] New micro-version needed for api bug fix or not?
On 05/29/2015 05:04 AM, John Garbutt wrote: On 29 May 2015 at 09:00, Sahid Orentino Ferdjaoui sahid.ferdja...@redhat.com wrote: On Fri, May 29, 2015 at 08:47:01AM +0200, Jens Rosenboom wrote: As the discussion in https://review.openstack.org/179569 still continues about whether this is just a bug fix, or an API change that will need a new micro version, maybe it makes sense to take this issue over here to the ML. Changing version of the API probably makes sense also for bug if it changes the behavior of a command/option to something backward incompatible. I do not believe it is the case for your change. My personal opinion is undecided, I can see either option as being valid, but maybe after having this open bug for four weeks now we can come to some conclusion either way. Apologies for this, we are still trying to evolve the rules for when to bump the API micro versions, there will be some pain while we work that out :( From the summit discussion, I think got three things roughly agreed (although we have not yet got them written up into a devref document, to make the formal agreement, and we need to do that ASAP): 1) We agreed changing a 500 error to an existing error (or making it succeed in the usual way) is a change that doesn't need a version bump, its a bug fix. 2) We also agreed that all micro version bumps need a spec, to help avoid is adding more bad things to the API as we try and move forward. This is heavy weight. In time, we might find certain good patterns where we want to relax that restriction, but we haven't done enough changes to agree on those patterns yet. This will mean we are moving a bit slower at first, but it feels like the right trade off against releasing (i.e. something that lands in any commit on master) an API with a massive bug we have to support for a long time. 3) Discuss other cases as they came up, and evolve the plans based on the examples that come up, with a focus on bumping the version being (almost) free, and useful for clients to work out what has changed. Is that how everyone else remembers that discussion? Yes. Now when it comes to your change. It is a bug in the default policy. Sadly this policy is also quite hard wired to admin vs non-admin. We still need work to make policy more discoverable, so I don't think we need to make this any more discoverable as such. Having said all that, we probably need to look at this case more carefully, after your patch has merged, and work out how this should work now we assuming strong validation, and granular policy, etc. Actually, after reading the IRC conversation between Dims and Sean, I believe Sean is right to want a microversion bump for this patch. If two clouds are deployed, one with this patch and another without, a client issuing commands to both will have no idea whether the ip6 filter will be considered or not. Having a microversion increment in the patch would allow clients to request behaviour they want (the ip6 filter). Best, -jay But maybe there is something massive here? Thanks, 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 __ 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
