Open Stack

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