Open Stack

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