Red Hat Bugzilla – Bug 1414526
Ceilometer events off by default but events are still saved to mongodb without TTL set
Last modified: 2018-02-05 14:04:43 EST
Description of problem: CeilometerStoreEvents defaults to off but events are still saved to mongodb. This causes mongodb to grow in size until the disk runs out because the event TTL is set to -1. store_events doesn't matter because events_dispatcher=database is configured by default thus causing events to be saved into mongodb without any ttl. Version-Release number of selected component (if applicable): OSP10 - Newton GA build How reproducible: Always Steps to Reproduce: 1. Deploy according to docs and view size of the event collection in mongodb 2. 3. Actual results: the event collection will grow in size as ceilometer stores events Expected results: If CeilometerStoreEvents is set to false, events should not be stored. Additional info: CeilometerStoreEvents set to false [0] CeilometerStoreEvents maps to store_events under agent notification configuration [1] events_dispatcher defaults to database in ceilometer puppet installer [2] event_time_to_live defaults to -1 in ceilometer puppet installer [3] This is due to CeilometerStoreEvents maps to store_events under agent_notification configuration section. [0] https://github.com/openstack/tripleo-heat-templates/blob/stable/newton/puppet/services/ceilometer-base.yaml#L43 [1] https://github.com/openstack/tripleo-heat-templates/blob/stable/newton/puppet/services/ceilometer-base.yaml#L100 [2] https://github.com/openstack/puppet-ceilometer/blob/stable/newton/manifests/collector.pp#L50 [3] https://github.com/openstack/puppet-ceilometer/blob/fc4a0fd5100128280703dbb3f8e109fb9393a2d0/manifests/init.pp#L235 There is likely some parameters we can pass into the deploy command to mitigate this issue.
I think this is something that ought to be fixed in Puppet recipes for Ceilometer. I'm assigning this to you Prad, but feel free to bump it elsewhere if it's wrong. :)
This should be fixed with collector deprecated.
Hi Can you either: - add the gerrit ID of the actual change so that we can doble check if we did got the actual fix? - or check if our current downstream build is OK? Thanks
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:3462