Open Stack

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
>