[openstack-dev] [Oslo] Using of oslo.config options in openstack.common modules
flavio at redhat.com
Wed Nov 13 08:11:13 UTC 2013
On 12/11/13 17:21 +0200, Roman Podoliaka wrote:
>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 :)
FWIW, We had a session about removing side-effects at the summit .
I can see the cases you mention being fixed as part of the work for
More information about the OpenStack-dev