ceilometer meter_time_to_live has no effect if applied to existing mongodb database
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ceilometer |
Invalid
|
Undecided
|
Unassigned | ||
ceilometer (Ubuntu) |
Invalid
|
Medium
|
Unassigned |
Bug Description
If metering_
https:/
This index was added in the fix for lp:1193906; however those commits did so without taking into account the TTL index.
In the default configuration of ceilometer and ceilometer-charm, this isn't a problem, because data is never expired. But because the manual expiry of data is gated on whether TTL indexes are supported by the mongodb version in use (see _is_natively_
Ideally, the code should be updated to create a TTL index if it is supported and a positive TTL is configured, and a non-TTL index if it is not supported (mongodb versions before 2.2), or TTL is non-positive.
Because mongodb is a deprecated storage driver for ceilometer, this isn't likely to be high priority or to be accepted by upstream, so I'll document the workaround here:
- Check if there's a TTL index on mongodb:
myset:PRIMARY> use ceilometer
switched to db ceilometer
myset:PRIMARY> db.meter.
...
- If an index called "meter_ttl" is present, ceilometer has configured a TTL index. Drop the non-TTL index:
myset:PRIMARY> db.meter.
Unfortunately, there's no indication in the mongodb documentation as to what will happen if "timestamp_idx" is recreated (which ceilometer seems to do on connection to mongodb). Hopefully the presence of the "meter_ttl" index should prevent "timestamp_idx" from breaking an existing TTL index, but I don't have any evidence to suggest one way or the other yet.
tags: | added: canonical-bootstack |
Status changed to 'Confirmed' because the bug affects multiple users.