Ceilometer

MongoDB tests fail with MIM

Bug #1052015 reported by Julien Danjou on 2012-09-17

6

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	Ceilometer	Fix Released	High	Unassigned	Ceilometer 2013.1 "grizzly"

Bug Description

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)

Tags:

Revision history for this message

John Tran (jtran) wrote on 2012-09-19:

#1

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

Revision history for this message

Julien Danjou (jdanjou) wrote on 2012-09-19:

#2

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

Revision history for this message

John Tran (jtran) wrote on 2012-09-19:

#3

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.

Revision history for this message

Doug Hellmann (doug-hellmann) wrote on 2012-09-27:

#4

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.

Changed in ceilometer:
status:	New → Triaged

Revision history for this message

Julien Danjou (jdanjou) wrote on 2012-10-04:

#5

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.

Revision history for this message

Doug Hellmann (doug-hellmann) wrote on 2012-10-05: Re: [Bug 1052015] Re: MongoDB tests fail with MIM

#6

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.

Revision history for this message

John Tran (jtran) wrote on 2012-10-31:

#7

This problem should be resolved with this patch:

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

Julien Danjou (jdanjou) on 2012-10-31

Changed in ceilometer:
status:	Triaged → Fix Committed

Thierry Carrez (ttx) on 2013-01-09

Changed in ceilometer:
milestone:	none → grizzly-2
status:	Fix Committed → Fix Released

Thierry Carrez (ttx) on 2013-04-04

Changed in ceilometer:
milestone:	grizzly-2 → 2013.1

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.