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