Open Stack

On Wed, Nov 13, 2013 at 4:13 AM, Roman Podoliaka <rpodolyaka at mirantis.com>wrote:

> 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).
>

This came up at one point during the summit and I believe the consensus was
that it made sense to try to push all of the Oslo libraries to not rely on
oslo.config as much as possible. That gets trickier with driver-based
libraries like messaging (where the options aren't known to the core
library), and for maintaining backwards compatibility for upgrades (since
we already have all of these configuration options). We also want to
minimize duplicate option definitions in the applications, which could end
up with different names or defaults.

I'm interested in whether anyone has suggestions for solving the issue
while addressing all of these cases.

Doug


>
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/313e0264/attachment.html>