Comment 4 for bug 1710831

Revision history for this message
Dmitrii Shcherbakov (dmitriis) wrote :

It's questionable which traits to add to event_definitions.yaml by default on the ceilometer side.

Each object has it's own set of traits (FIELDS) + inherited traits from base classes.

class Pool(base.DictObjectMixin, base.PersistentObjectMixin,
           base.DesignateObject):
    FIELDS = {

I would say that ceilometer needs to render event_definitions.yaml with a sane set of default event definitions but should allow one to supply a completely arbitrary event_definitions.yaml.

I could add PersistentObjectMixin and DesignateObject at least.

event_definitions.yaml is highly customizable and I do not think it is necessary to preseed it - it should just be taken from a user because modeling and parsing event and trait definitions in a charm is cumbersome. Another reason is that an operator may want to reduce unnecessary chatter in telemetry but given a charm manages the config it's not possible to just go and edit it.

https://docs.openstack.org/ceilometer/pike/contributor/events.html#definitions-file-format

Likewise, meters.yaml should be replaceable as well https://github.com/openstack/ceilometer/blob/stable/pike/ceilometer/data/meters.d/meters.yaml

This is necessary to avoid charm forks just to add another trait or two.