The goal of this blueprint is to capture the notification events emitted by Designate (DNSaaS) during create, update and delete operations.
Designate (designate-central) emits notifications in response to user actions by designate-api and other openstack service (nova, neutron) events by designate-sink.
These notifications are CRUD events, that notify the creation, update or delete of a DNS resource, with no specific measurement value.
Ceilometer needs to be updated to consume and record these notifications as events and traits.
If Ceilometer processes and record these notifications, other services will be able to use this for aggregation and billing purpose.
Define event definitions and field mappings(trait definitions) for DNS resource types - domain, record in the /etc/ceilometer/event_definitions.yaml file.
The trait field syntax in trait definitions follow a variant of the JSONPath.
Example of the event definition and field mappings for the domain notifications that need to go in event_definitions.yaml,
To enable event processing in Ceilometer, configuration is needed in ceilometer.conf,
eg - [notification] store_events = True
eg - [event] definitions_cfg_file = event_definitions.yaml
The dns event types have the following pattern,
, where resource is domain, record, pool.
Transform DNS notifications as samples using notification plugin to listen for notifications at an exchange and topic. This could be useful when the notifications represent something other than CRUD events that contain a value of interest that can be measured.
Using events provides better querying of metadata and avoids the effort to aggregate samples with a fixed measurement value of 1.
No new impacts. Pre-existing concerns with capacity at the notification and storage handling layers remain.
In the future Designate will emit the dns.domain.exists event. This will need to be handled when designate emits this notification.
The set of dns resource types - (domain, record, pool) may change going forward. There could be new types of notifications which will need to be supported.
When Designate confirms with the PaaS event format, the field mappings for integrated events will need to be refactored to adjust to the new event format.
DNSaaS is construed as a PaaS service by some and might have it own message bus where it is sending notifications. Ceilometer recently was extended to consume notification from multiple message bus - https://review.openstack.org/#/c/77612/
If there are multiple message buses, then ceilometer will need multiple transport endpoints configured in ceilometer configuration. (ceilometer.conf)
Unit and integration Tests will be added to validate events generated.