Open Stack

Hi Flavio,

Thanks for sharing this! I attended that session, but haven't seen the
corresponding blueprint before.

Nevertheless, I'm not sure that implementing this entirely solves the
original problem. Removing import side-effects is definitely the right
thing to do, but options will be eventually registered at runtime
anyway, so they could possibly conflict (e.g. Ironic uses oslo.db and
lockutils, oslo.db uses lockutils too, but with newer definitions of
the same options, so even if we moved registration of options to
lockutils.synchronized() function, they would conflict when the
function would be called).

Thanks,
Roman

On Wed, Nov 13, 2013 at 10:11 AM, Flavio Percoco <flavio at redhat.com> wrote:
> On 12/11/13 17:21 +0200, Roman Podoliaka wrote:
>>
>> Hi all,
>>
>> Currently, many modules from openstack.common package register
>> oslo.config options. And this is completely OK while these modules are
>> copied to target projects using update.py script.
>>
>> But consider the situation, when we decide to split a new library from
>> oslo-incubator - oslo.spam - and this library uses module
>> openstack.common.eggs, just because we don't want to reinvent the
>> wheel and this module is really useful. Lets say module eggs defines
>> config option 'foo' and this module is also used in Nova. Now we want
>> to use oslo.spam in Nova too.
>>
>> So here is the tricky part: if the versions of openstack.common.eggs
>> in oslo.spam and openstack.common.eggs in Nova define config option
>> 'foo' differently (e.g. the version in Nova is outdated and doesn't
>> provide the help string), oslo.config will raise DuplicateOptError.
>>
>> There are at least two ways to solve this problem:
>> 1) don't use openstack.common code in olso.* libraries
>> 2) don't register config options in openstack.common modules
>>
>> The former is totally doable, but it means that we will end up
>> repeating ourselves, because we already have a set of very useful
>> modules (e.g. lockutils) and there is little sense in rewriting them
>> from scratch within oslo.* libraries.
>>
>> The latter means that we should refactor the existing code in
>> openstack.common package. As these modules are meant to be libraries,
>> it's strange that they rely on config values to control their behavior
>> instead of using the traditional approach of passing
>> function/method/class constructor arguments.
>>
>> ...or I might be missing something :)
>>
>> Thoughts?
>
>
> FWIW, We had a session about removing side-effects at the summit [0].
> I can see the cases you mention being fixed as part of the work for
> that blueprint.
>
> [0] http://summit.openstack.org/cfp/details/125
>
> --
> @flaper87
> Flavio Percoco
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev