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.