I also learn that from Sean! -----Original Message----- From: Jay Pipes [mailto:[email protected]] Sent: Saturday, May 30, 2015 2:58 AM To: [email protected] 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 > <[email protected]> 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: > [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
