test failures in release oslo-config-1.4.0; FAILED (id=x, failures=5)

[IAN DELANEY]

cd to the source and run it manually using testrepoitory; do the testr init first then

/oslo.config-1.4.0 $ PYTHONPATH=. testr run

running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ .
======================================================================
FAIL: unittest.loader.ModuleImportFailure.tests.test_cfg
tags: worker-0
----------------------------------------------------------------------
Traceback (most recent call last):
ImportError: Failed to import test module: tests.test_cfg
Traceback (most recent call last):
  File "/usr/lib64/python2.7/unittest/loader.py", line 254, in _find_tests
    module = self._get_module_from_name(name)
  File "/usr/lib64/python2.7/unittest/loader.py", line 232, in _get_module_from_name
    __import__(name)
  File "tests/test_cfg.py", line 258, in <module>
    class CliOptsTestCase(BaseTestCase):
  File "tests/test_cfg.py", line 269, in CliOptsTestCase
    IPv4Opt = functools.partial(cfg.IPOpt, version=4)
AttributeError: 'module' object has no attribute 'IPOpt'
======================================================================
FAIL: unittest.loader.ModuleImportFailure.tests.test_cfgfilter
tags: worker-0
----------------------------------------------------------------------
Traceback (most recent call last):
ImportError: Failed to import test module: tests.test_cfgfilter
Traceback (most recent call last):
  File "/usr/lib64/python2.7/unittest/loader.py", line 254, in _find_tests
    module = self._get_module_from_name(name)
  File "/usr/lib64/python2.7/unittest/loader.py", line 232, in _get_module_from_name
    __import__(name)
  File "tests/test_cfgfilter.py", line 18, in <module>
    from oslo.config import cfgfilter
ImportError: cannot import name cfgfilter
======================================================================
FAIL: unittest.loader.ModuleImportFailure.tests.test_fixture
tags: worker-0
----------------------------------------------------------------------
Traceback (most recent call last):
ImportError: Failed to import test module: tests.test_fixture
Traceback (most recent call last):
  File "/usr/lib64/python2.7/unittest/loader.py", line 254, in _find_tests
    module = self._get_module_from_name(name)
  File "/usr/lib64/python2.7/unittest/loader.py", line 232, in _get_module_from_name
    __import__(name)
  File "tests/test_fixture.py", line 21, in <module>
    from oslo.config import fixture as config
ImportError: cannot import name fixture
======================================================================
FAIL: unittest.loader.ModuleImportFailure.tests.test_generator
tags: worker-0
----------------------------------------------------------------------
Traceback (most recent call last):
ImportError: Failed to import test module: tests.test_generator
Traceback (most recent call last):
  File "/usr/lib64/python2.7/unittest/loader.py", line 254, in _find_tests
    module = self._get_module_from_name(name)
  File "/usr/lib64/python2.7/unittest/loader.py", line 232, in _get_module_from_name
    __import__(name)
  File "tests/test_generator.py", line 24, in <module>
    from oslo.config import fixture as config_fixture
ImportError: cannot import name fixture
======================================================================
FAIL: unittest.loader.ModuleImportFailure.tests.test_types
tags: worker-0
----------------------------------------------------------------------
Traceback (most recent call last):
ImportError: Failed to import test module: tests.test_types
Traceback (most recent call last):
  File "/usr/lib64/python2.7/unittest/loader.py", line 254, in _find_tests
    module = self._get_module_from_name(name)
  File "/usr/lib64/python2.7/unittest/loader.py", line 232, in _get_module_from_name
    __import__(name)
  File "tests/test_types.py", line 381, in <module>
    class IPAddressTypeTests(TypeTestHelper, unittest.TestCase):
  File "tests/test_types.py", line 382, in IPAddressTypeTests
    type = types.IPAddress()
AttributeError: 'module' object has no attribute 'IPAddress'
Ran 22 tests in 0.005s (-0.000s)
FAILED (id=5, failures=5)

without fail, excuse the pun, these occur subsequent to the tests being seemingly unable to import its own core classes or modules in oslo.config. No idea how or why but they don't import.

The first;

oslo.config-1.4.0 $ PYTHONPATH=. python -c "from oslo.config.cfg import IPOpt"
yields
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name IPOpt

oslo.config-1.4.0 $ PYTHONPATH=. python -c "from oslo.config import cfgfilter"
yields
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name cfgfilter

through to

PYTHONPATH=. python -c "from oslo.config.types import IPAddress"
yields
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name IPAddress

whereas attempt to import another class from oslo/config/types.py;

/oslo.config-1.4.0 $ PYTHONPATH=. python -c "from oslo.config.types import Integer" OR Float
happily import.

Now this is the part that has me most puzzled. This holds for py2.7 Make eselected system python 3.3 and it passes fine. It's 'always' the other way around.

[Doug Hellmann (doug-hellmann)]

We generally expect the tests to run through tox, not directly. I suspect tox is doing something extra to prepare the egg for oslo.config, which configures the namespace package to the code will import properly. Can you use tox to run the tests?

[IAN DELANEY (johneed)]

Doug.
Yes and no. This I have spent quite some time on however in the end it appears to be erroneous but at a level too low for me to determine.
This is gentoo. I have just made a new extra gentoo system and the phenomenon repeated in s similar style. However, another gentoo dev who has an interest in this packages has it pass fine in py2.7, with the same minor version, which is enough to proclaim "something funny in your system" only I have no clue what that could be. Gentoo has fairly strict controls to ensure uniformity in system states so the inability for him to replicate while I get it in TWO systems us both quite miffed.
Can you use tox to run the tests?

Yes but I won't. Now here's the 'thing' tox is nice but it's not the panacea developers like to make it out to be. Testing in tox is testing in a virtualenv. In a gentoo ebuild, gentoo's own policies and processes render tox totally toxic 'cause it does what tox does, namely d'load everything all over again from the net and then run an ACTUAL test run cmd.

So; gentoo process says NO d'loading beyond fetching the source. Then tox comes along and d'loads everything for each python impl. NO GO. What we're left with then is within an ebuild, a test phase need run the test suite against the deps and all in the installed gentoo system, which when you think about it is actually a pretty valid exercise.

In an ebuild what I do is take the cmds to run the testsuite from the tox.ini and use those. The use of tox is by it's nature banned. However all this is just to edify you about gentoo style. What I need is a cross tester to see if there's any replication prospects in these findings. Even then your hard coded use of tox puts us at odds. This is looking to be some (invisible) oddity in my system(s) and the tests are likely fine. My py2.7 passes other testsuites fine so really don't know what gives here.

[IAN DELANEY (johneed)]

this passes fine with a cross test. No idea how this occurred

[Bharath Krishna M (m-bharathkrishna)]

I am still facing this issue during devstack installation. Couldn't find resolution. Can you please suggest how to proceed further? Thanks in advance.

[Doug Hellmann (doug-hellmann)]

Ian, I'm not sure what a "cross test" is but it sounds like you've solved your configuration issue. If not, please reopen the ticket.

Bharath, if you're developing please use tox to run the tests. The environment tox sets up should match what is run in the CI environment. If you're not developing, please stop by #openstack-oslo or start a mailing list thread on openstack-dev and we will see what we can do to help you figure out what's broken.