MongoDB tests fail with MIM

[Julien Danjou]

MongoDB tests pass correctly with real MongoDB, but with MIM it fails:

======================================================================
FAIL: test_get_raw_events_by_both_times (tests.storage.test_impl_mongodb.MeterTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jd/Work/src/ceilometer/tests/storage/test_impl_mongodb.py", line 364, in test_get_raw_events_by_both_times
    assert length == 1
AssertionError:
    [] = list(self.conn.get_raw_events(<ceilometer.storage.EventFilter object at 0x3923150>))
    0 = len([])
>> assert 0 == 1
    assert [][0]['timestamp'] == <module 'datetime' from '/usr/lib/python2.7/lib-dynload/datetime.so'>.<module 'datetime' from '/usr/lib/python2.7/lib-dynload/datetime.so'>(2012, 7, 2, 10, 42)

======================================================================
FAIL: test_get_resources_both_timestamps (tests.storage.test_impl_mongodb.ResourceTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jd/Work/src/ceilometer/tests/storage/test_impl_mongodb.py", line 287, in test_get_resources_both_timestamps
    assert set(resource_ids) == expected
AssertionError:
    [] = [r['resource_id'] for r in []]
    set(['resource-id-2']) = set(['resource-id-2'])
>> assert set([]) == set(['resource-id-2'])

----------------------------------------------------------------------
Ran 126 tests in 0.415s

FAILED (SKIP=11, failures=2)

[John Tran (jtran)]

From mailing list:

Are you using the version of Ming from https://github.com/dreamhost/Ming? It has some patches that may not have been accepted upstream, yet (I'm working with Rick Copeland on that). Our test requirements file should be pointing to that version, but it probably won't upgrade cleanly if you already had something installed. Try "tox -r -e py27" to rebuild the test virtualenv and see if that helps.

Doug

[Julien Danjou (jdanjou)]

I've re-run tons of tox -r and it always fail. Can't you reproduce it Doug?

[John Tran (jtran)]

I was able to resole this issue by pip uninstall Ming from my non-venv , delete the .tox dir, and then re-run tox so that it re-installs the venv but that didn't fully resolve it... I had to then install Ming in my non-venv for it to fully register, otherwise running tox -epy27 still would give me errors that mim wasn't installed.

[Doug Hellmann (doug-hellmann)]

I wonder if uninstalling it in the non-venv location actually removed enough of it? Usually that works, but it doesn't make sense that you would need to install there if the CI environment can successfully run without having ming installed globally.

[Julien Danjou (jdanjou)]

Following John advice, I did the same, and it worked. You have to install Ming into your non-virtual environment, because for whatever reason nose cannot find the Ming module in the tox virtual env. Running python in the virtual env and typing "import ming" just works, but it seems that nose is overriding "import" with its own code, and it can find Ming. So having it in the non venv makes things work.

Looks like a bug in Ming and/or nose to me.

[Doug Hellmann (doug-hellmann)]

On Thu, Oct 4, 2012 at 10:18 AM, Julien Danjou
<email address hidden>wrote:

> Following John advice, I did the same, and it worked. You have to
> install Ming into your non-virtual environment, because for whatever
> reason nose cannot find the Ming module in the tox virtual env. Running
> python in the virtual env and typing "import ming" just works, but it
> seems that nose is overriding "import" with its own code, and it can
> find Ming. So having it in the non venv makes things work.
>
> Looks like a bug in Ming and/or nose to me.

It could be. I think I do have it configured that way on my dev system from
before the time when tox was configured and working properly.

[John Tran (jtran)]

This problem should be resolved with this patch:

https://review.openstack.org/#/c/15079/