Replied in line with prefix [alex] -----Original Message----- From: John Garbutt [mailto:[email protected]] 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 <[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. [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: [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
