Ceilometer/blueprints/tighten-model
Context
In Ceilometer, our basic Sample is a named tuple. Samples have no relation between them. So it's valid to send the following:
Sample(user_id='foo', resource_id='123abc', meter='bar', volume=123) Sample(user_id='xyz', resource_id='123abc', meter='bar', volume=234)
While resources don't see their owner changeable in OpenStack, since Ceilometer does not only support OpenStack but anything, it is allowed to do so.
Problem
While this is true in theory and in the MongoDB driver at least, the Ceilometer API is unable to reflect that. For example, when retrieving a resource:
GET /v2/resources/123abc
{
[...]
"resource_id": "123",
"timestamp": "2013-10-26T13:10:12.914529",
"user_id": "xyz"
}
The API will return only one resource, and in this case one user_id, likely the latest one inserted in the database. This is not very useful and wrong in the end.
Also, allowing this kind of very flexible storage kills performances in a terrible way for most data storage. MongoDB has to large data aggregation and the SQL driver can't split things across several tables in an efficient way. Having a more "normalized" data store would help a lot.
I think the flexibility provided by just storing "sample" is not needed in the OpenStack monitoring, is a good enough trade-off for other potential platforms.
Solution
The solution would be to:
- Define a proper data model. For example, assuming that a resource always belongs to one and the same user and projects. That should be done in ceilometer.storage.models likely.
- Enhance the storage drivers in this regard.
- Fix the v2 API as far as possible, and probably prepare a cleaner v3 API implementing leveraging this data model.
