[openstack-dev] [ceilometer] Possible issue with MongoDB storage resource ID

Bhandaru, Malini K malini.k.bhandaru at intel.com
Sat Nov 17 00:02:17 UTC 2012


Cleanest way seems to use uuid for resource-id.

From: Doug Hellmann [mailto:doug.hellmann at dreamhost.com]
Sent: Friday, November 16, 2012 3:11 PM
To: openstack-dev at lists.openstack.org; Doug Hellmann
Subject: Re: [openstack-dev] [ceilometer] Possible issue with MongoDB storage resource ID


On Fri, Nov 16, 2012 at 8:57 AM, Julien Danjou <julien at danjou.info<mailto:julien at danjou.info>> wrote:
Hi,

I was working on fixing a bug in the API, and wrote a test that
unexpectedly failed.

Digging, I've discovered that it's currently a problem on how the
MongoDB storage handles its `resource' collection: you can't have 2
resource with the same id even if they came from 2 different sources.
Meaning that if you record:

  Counter(source='abc', resource_id='foobar')
  Counter(source='def', resource_id='foobar')

You'll end up with the 'source' field being overwritte because the
resource collection use resource_id as its MongoDB _id field.

So in the end, the request '/sources/abc/resources/foobar' returns
nothing.

This seems like a bug to me, because I easily imagine external systems
with different source values having resource-id that can collide,
because they're not UUID or the like.

Doug, what's your opinion this, and how to fix it?

I'm not sure we can tell, from the inside of ceilometer, what a unique identifier for a resource described by a given meter event should be. I think the intent was that the sender would do whatever was necessary to ensure it was unique. If the sender is concerned about collisions, it could prefix the resource id with some constant identifying the sender.

Doug



--
Julien Danjou
# Free Software hacker & freelance
# http://julien.danjou.info

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121117/ef281d94/attachment.html>


More information about the OpenStack-dev mailing list