[openstack-dev] Recent oslo.config/Quantum changes [was Re: For those using Quantum with devstack]

Salvatore Orlando sorlando at nicira.com
Fri May 24 22:00:21 UTC 2013


Hi Mark,

Your comments where not really TL, but I thank your very much for the TL;DR
follow up!
And btw, thank you very much for [1]!

oslo.config 1.2.0 does normalize all option group names to lowercase, but
still supports as 'deprecated' the ones with all capital letters.
Is the above statement correct?
I'm asking because during a review I expressed a similar concern and was
told that oslo.config 1.1.0 did this ([2]), and I want to be sure my
understanding is correct.

It seems that Akihiro is on top of this, and is already updating
pip-requires to point to 1.2.0a1, so hopefully everything is sorted.

[1] https://review.openstack.org/#/c/30250/
[2] https://review.openstack.org/#/c/29176/


On 23 May 2013 12:45, Mark McLoughlin <markmc at redhat.com> wrote:

> On Thu, 2013-05-23 at 12:28 +0100, Mark McLoughlin wrote:
> > Hey
> >
> > Let me try and summarize a few things about this:
>
> Since this is definitely TL and I expect there'll be plenty who don't
> TR, let me TL;DR :)
>
>   1) the breakage people saw in Quantum was due to the fact the Quantum
>      merged changes requiring latest oslo.config and it wasn't
>      available. This should never have gotten through the gate, but it
>      did.
>
>   2) we don't intentionally make incompatible changes in oslo.config.
>      We did accidentally make one and it broke a fairly obscure part of
>      Quantum. We've reverted that incompatible change. Again, though,
>      this was not the cause of the Quantum breakage people noticed.
>
>   3) we need to figure out a better way for all the development
>      branches of our integrated projects to use the development version
>      of oslo.config.
>
> Cheers,
> Mark.
>
> >   - a change went into oslo.config master (what will be 1.2.0) to
> >     normalize config file section names to lowercase
> >
> >     the compat concerns are pretty subtle here:
> >
> >       1) the only way this change would have (intentionally) caused
> >          breakage is where a project was doing something like this:
> >
> >            [foo]
> >            bar = blaa
> >
> >            [FOO]
> >            bar = boo
> >
> >          and expected to see CONF.foo == blaa and CONF.FOO.bar == boo.
> >          That's incredibly unlikely, but if it turns out that a project
> >          was doing that, we will have to revert the change. That's why
> >          we don't publish dev release to pypi - we want to give
> >          ourselves a chance to find these issues on the dev branch
> >          before breaking stable pypi-based deployments. Again, I
> >          sincerely doubt this case is going to be a problem.
> >
> >       2) there was some confusion in Quantum and some interpreted this
> >          change as meaning that they would need to replace e.g. CONF.OVS
> >          to CONF.ovs in the codebase in order to upgrade to latest
> >          oslo.config.
> >
> >          If that was true, this would have been a massively
> >          incompatible change and would completely hose Grizzly
> >          deployments if you upgraded oslo.config. All the noise I make
> >          about API compatibility is about avoiding that exact situation.
> >          We do not (intentionally) make those kind of incompatible
> >          changes in oslo.config.
> >
> >          In order to change the case of the references in the code
> >          base, you have to explicitly opt-in by doing:
> >
> >            -CONF.register_opts(opts, group='OVS')
> >            +CONF.register_opts(opts, group='ovs')
> >
> >          and you can do that group-by-group.
> >
> >          Summary: Quantum could have upgraded to latest oslo.config
> >          with *zero* code changes.
> >
> >       3) we did actually make an incompatible change to a part of the
> >          oslo.config API that we thought no-one was using. As soon as
> >          it became apparent that one of the Quantum drivers was using
> >          it, we jumped on the issue and restored the previous API
> >          semantics:
> >
> >            https://review.openstack.org/30250
> >
> >   - These changes to Quantum:
> >
> >       b8b2c4e Reference OVS OptGoup names in lowercase
> >       2f13345 Reference DEFAULT_SERVICETYPE OptGoup names in lowercase
> >       362bd7f Reference QUOTA OptGoup names in lowercase
> >
> >     require latest oslo.config. They should not have been merged before
> >     we changed pip-requires to use the latest oslo.config:
> >
> >       https://review.openstack.org/30094
> >
> >     I don't fully understand yet how these changes got through the gate
> >     before the newer version of oslo.config was even available.
> >
> >   - I've tagged oslo.config-1.2.0a1 yesterday and I'll tag 1.2.0a2
> >     later today hopefully. The 1.2.0 release won't be pushed to pypi
> >     until Havana is almost ready to be released. This is to give us a
> >     chance to catch issues like the MultiConfigParser breakage above.
> >
> >     In the meantime, all Havana development and testing should be using
> >     the oslo.config 1.2.0 branch (i.e. master) - currently the only way
> >     we have of doing that is to update each project's pip-requires file
> >     to point to the oslo.config tarball on tarballs.openstack.org
> >
> > Hope that helps,
> > Mark.
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130524/c8d97f39/attachment.html>


More information about the OpenStack-dev mailing list