cardinality of storage.models.Resource.meter attribute is one-per-sample
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ceilometer |
Fix Released
|
High
|
Eoghan Glynn | ||
Havana |
Fix Released
|
High
|
Eoghan Glynn |
Bug Description
At least in the mongodb and sqlalchemy cases (and most likely for all storage drivers), the meter attribute of the Resource model has an entry for every single sample associated with the given resource.
This results in an extremely long and repetitive list of meter (name,type,unit) tuples, which is then promptly discarded as the meter link hrefs in the API Resource representation are recreated from separate get_meters calls on the storage driver (one per unique resource ID in the result set for the GET /v2/resources query).
So we've created a huge scaling issue, for no good reason.
We should either:
1. just stop populating the Resource.meter in the storage model, as it's currently unused, contains much redundant information, and is expensive to construct in memory
or:
2. ensure the Resource.meter list is dupe-free and suppress the multiple calls into get_meters for each resource ID to create the resource links
description: | updated |
Changed in ceilometer: | |
assignee: | nobody → Eoghan Glynn (eglynn) |
milestone: | none → icehouse-2 |
Changed in ceilometer: | |
status: | Triaged → In Progress |
tags: | added: havana-backport-potential |
tags: | removed: havana-backport-potential |
Changed in ceilometer: | |
status: | Fix Committed → Fix Released |
Changed in ceilometer: | |
milestone: | icehouse-2 → 2014.1 |
Sounds like we should go for 1.