Declarative Notification Handling¶
https://blueprints.launchpad.net/ceilometer/+spec/declarative-notifications
The goal of this spec is to propose a more declarative approach to defining notification events.
Problem description¶
The existing implementation of notification handling has various limitations. The issues this proposal addresses include:
There is no way to selectively listen to specific event topics of interest.
Capturing notifications of interest should not require code changes.
Adding new event exchanges involves same routine code changes. Too much code duplication.
Requires more insight into the code base than needed
more elegant exchange control
This proposal takes a more declarative approach in addressing these concerns.
Proposed change¶
Firstly, we define a notification event template where the event signature and attributes are set. This is simple yaml file of the following format:
---
resources:
- name: image
type: "gauge"
topics:
- "image.size"
volume: payload.size
unit: B
counter_name: image.size
tenant_id: payload.tenant_id
user_id: payload.user_id
instance_id: payload.instance_id
This essentially depicts the boiler plate code we add in notifications.py. A base notification handler loads the event definition and does the rudimentary steps of calling the process_notifications and yielding samples. The advantage of this is that in future when new events need to be added, the end user only need to update the yaml.
Also note that we’re in the process of deprecating existence meters. All the current existence meters will be put at the bottom of the template file with a note saying they will be removed in ‘M’ release.
Secondly, we need to elegantly handle exchange control as part of this definition. The exchanges are specified in ceilometer.conf
We already have exchange definitions as part of ceilometer.conf. We could leverage these as it is and assume that if these are defined then we will enable them. We could also add a new option to specify all the exchanges we like to allow with same exchange name as defined. These exchanges will be read by the base notification handler and get_targets logic will loop through the allowed exchanges and sets up the exchanges. If an event name is part of the exchange names, we’ll skip processing these notifications and move on.
Alternatives¶
We could leverage the existing event_definition.yaml used for conversion. But i’m not sure how free flowing and flexible that would be. I’m open to this idea.
Data model impact¶
None
REST API impact¶
None
Security impact¶
None
Pipeline impact¶
None
Other end user impact¶
None
Performance/Scalability Impacts¶
None
Other deployer impact¶
None
Developer impact¶
None
Implementation¶
Assignee(s)¶
- Primary assignee:
Pradeep Kilambi <pkilambi@redhat.com>
- Other contributors:
Pradeep Kilambi <pkilambi@redhat.com>
Work Items¶
Work items: * Define Event notification template * Implement generic notification handler to process the template and generate samples * Add support for handling exchange control * Clean up existing handlers * Add and update test coverage
Future lifecycle¶
None
Dependencies¶
None
Testing¶
Add unit test coverage
Documentation Impact¶
Document new ways of enabling notification events and exchanges via the template file with examples.