Re: [openstack-dev] [Oslo] Using of oslo.config options in openstack.common modules
On Wed, Nov 13, 2013 at 4:13 AM, Roman Podoliaka 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 > 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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] Using of oslo.config options in openstack.common modules
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 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] Using of oslo.config options in openstack.common modules
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
