Open Stack

I also learn that from Sean!

-----Original Message-----
From: Jay Pipes [mailto:jaypipes at gmail.com] 
Sent: Saturday, May 30, 2015 2:58 AM
To: openstack-dev at 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.ferdjaoui at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev