[openstack-dev] A question about strange behavior of oslo.config in eclipse

Doug Hellmann doug at doughellmann.com
Fri Feb 13 23:05:59 UTC 2015



On Thu, Feb 12, 2015, at 07:19 AM, Joshua Zhang wrote:
> Hi Doug,
> 
>    Thank you very much for your reply. I don't have any codes, so no any
> special codes as well.
>    Only thing I did is that:
>    1, use devstack to install a fresh openstack env, all are ok.
>    2, import neutron-vpnaas directory (no any my own codes) into eclipse
>    as
> pydev project, for example, run unit test
> (neutron_vpnaas.tests.unit.services.vpn.test_vpn_service ) in eclipse, it
> throws the following exception.
>    3, but this unit test can be run well in bash, see
> http://paste.openstack.org/show/172016/
>    4, this unit test can also be run well in eclipse as long as I edit
> neutron/openstack/common/policy.py file to change oslo.config into
> oslo_config.
> 
> 
> ======================================================================
> ERROR: test_add_nat_rule
> (neutron_vpnaas.tests.unit.services.vpn.test_vpn_service.TestVPNDeviceDriverCallsToService)
> neutron_vpnaas.tests.unit.services.vpn.test_vpn_service.TestVPNDeviceDriverCallsToService.test_add_nat_rule
> ----------------------------------------------------------------------
> _StringException: Traceback (most recent call last):
>   File
> "/bak/openstack/neutron-vpnaas/neutron_vpnaas/tests/unit/services/vpn/test_vpn_service.py",
> line 98, in setUp
>     super(TestVPNDeviceDriverCallsToService, self).setUp()
>   File
> "/bak/openstack/neutron-vpnaas/neutron_vpnaas/tests/unit/services/vpn/test_vpn_service.py",
> line 53, in setUp
>     super(VPNBaseTestCase, self).setUp()
>   File "/bak/openstack/neutron-vpnaas/neutron_vpnaas/tests/base.py", line
> 36, in setUp
>     override_nvalues()
>   File "/bak/openstack/neutron-vpnaas/neutron_vpnaas/tests/base.py", line
> 30, in override_nvalues
>     cfg.CONF.set_override('policy_file', neutron_policy)

Yes, this line is trying to force the value of a policy module
configuration value but the test file does not previously import the
module where that option is defined.

For now, you should investigate the fixture class in oslo.config [1],
and update the test class to use ConfigOpts.import_opt() to ensure the
policy option is defined.

After the oslo.policy library is released (and neutron is updated to use
it instead of the incubated version of that code), the tests will need
to be changed again to use an API to update the setting because
configuration options are not part of the public API for Oslo libraries.
I filed a bug against oslo.policy to track the need for that change [2].

Doug

[1] http://docs.openstack.org/developer/oslo.config/fixture.html
[2] https://bugs.launchpad.net/oslo.policy/+bug/1421869

>   File "/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line
> 1679, in __inner
>     result = f(self, *args, **kwargs)
>   File "/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line
> 1949, in set_override
>     opt_info = self._get_opt_info(name, group)
>   File "/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line
> 2262, in _get_opt_info
>     raise NoSuchOptError(opt_name, group)
> NoSuchOptError: no such option: policy_file
> 
> On Tue, Feb 10, 2015 at 10:38 PM, Doug Hellmann <doug at doughellmann.com>
> wrote:
> 
> >
> >
> > On Tue, Feb 10, 2015, at 04:29 AM, Joshua Zhang wrote:
> > > Hi Stacker,
> > >    A question about oslo.config, maybe a very silly question. but pls
> > >    tell
> > > me if you know, thanks in advance.
> > >
> > >    I know oslo has removed 'olso' namespace, oslo.config has been changed
> > > to oslo_config, it also retains backwards compat.
> > >
> > >    I found I can run openstack successfully, but as long as I run
> > >    something
> > > in eclipse/pydev it always said like 'NoSuchOptError: no such option:
> > > policy_file'. I can change 'oslo.config' to 'oslo_config' in
> > > neutron/openstack/common/policy.py temporarily to bypass this problem
> > > when
> > > I want to debug something in eclipse. But I want to know why? who can
> > > help
> > > me to explain ? thanks.
> >
> > It sounds like you have code in one module using an option defined
> > somewhere else and relying on import ordering to cause that option to be
> > defined. The import_opt() method of the ConfigOpts class is meant to
> > help make these cross-module option dependencies explicit [1]. If you
> > provide a more detailed traceback I may be able to give more specific
> > advice about where changes are needed.
> >
> > Doug
> >
> > [1]
> >
> > http://docs.openstack.org/developer/oslo.config/configopts.html?highlight=import_opt#oslo_config.cfg.ConfigOpts.import_opt
> >
> > >
> > >
> > > --
> > > Best Regards
> > > Zhang Hua(张华)
> > > Software Engineer | Canonical
> > > IRC:  zhhuabj
> > >
> > __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 
> 
> -- 
> Best Regards
> Zhang Hua(张华)
> Software Engineer | Canonical
> IRC:  zhhuabj



More information about the OpenStack-dev mailing list