Consume the notification events emitted by Designate (DNSaaS) in Ceilometer. blueprint dns-service-notifications Change-Id: I9226b98727eacf567ee3a5b1acdb48608cfad9d9
5.0 KiB
Track DNS Service Notifications
https://blueprints.launchpad.net/ceilometer/+spec/dns-service-notifications
The goal of this blueprint is to capture the notification events emitted by Designate (DNSaaS) during create, update and delete operations.
Problem description
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.
Proposed change
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,
- event_type: dns.domain.*
- traits: &dns_domain_traits
- status:
- fields: payload.status
- retry:
- fields: payload.retry
- description:
- fields: payload.description
- expire:
- fields: payload.expire
- email:
- fields: payload.email
- ttl:
- fields: payload.ttl
- action:
- fields: payload.action
- name:
- fields: payload.name
- id:
- fields: payload.id
- created_at:
- fields: payload.created_at
- updated_at:
- fields: payload.updated_at
- version:
- fields: payload.version
- parent_domain_id:
- fields: parent_domain_id
- serial:
- fields: payload.serial
To enable event processing in Ceilometer, configuration is needed in ceilometer.conf,
- Configure store_events as True under the notification section,
eg -[notification] store_events = True
- Specify the event_definitions file name under the event section,
eg -[event] definitions_cfg_file = event_definitions.yaml
The dns event types have the following pattern,
- dns.<resource>.create
- dns.<resource>.update
- dns.<resource>.delete
, where resource is domain, record, pool.
Alternatives
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.
Data model impact
None.
REST API impact
None.
Security impact
None.
Pipeline impact
None.
Other end user impact
None.
Performance/Scalability Impacts
No new impacts. Pre-existing concerns with capacity at the notification and storage handling layers remain.
Other deployer impact
None.
Developer impact
None.
Implementation
Assignee(s)
- Primary assignee:
-
rjaiswal
- Ongoing maintainer:
-
rjaiswal
Work Items
- Event definitions and field mappings for all supported DNS resource types.
- Event validation.
Future lifecycle
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.
Dependencies
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)
Testing
Unit and integration Tests will be added to validate events generated.
Documentation Impact
None.
References
http://docs.openstack.org/developer/ceilometer/events.html
http://docs.openstack.org/trunk/config-reference/content/ch_configuring-openstack-telemetry.html