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:
 * 1) 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.
 * 2) Enhance the storage drivers in this regard.
 * 3) Fix the v2 API as far as possible, and probably prepare a cleaner v3 API implementing leveraging this data model.