Comment 3 for bug 1710831

So, to break the comms down, designate components do both sending and receiving via AMQP.

1. nova to designate

https://git.io/vFMbn
nova -> {compute.instance.create.end, compute.instance.delete.start} -> designate-sink -> nova-handler

cfg.CONF.register_opts([
    cfg.ListOpt('notification-topics', default=['notifications']),
    cfg.StrOpt('control-exchange', default='nova'),

2. neutron to designate

https://git.io/vFMb8
neutron -> {floatingip.update.end, floatingip.delete.start} -> designate-sink -> neutron-handler

cfg.CONF.register_opts([
    cfg.ListOpt('notification-topics', default=['notifications']),
    cfg.StrOpt('control-exchange', default='neutron'),

https://docs.openstack.org/designate/pike/contributor/architecture.html#designate-sink
designate-sink is an optional service which listens for event Notifications, such as compute.instance.create.end, handlers are available for Nova and Neutron. Notification events can then be used to trigger record creation & deletion.

3. central -> other consumers (e.g. ceilometer-agent-notification)

https://github.com/openstack/designate/blob/stable/ocata/designate/central/service.py#L163-L164
https://github.com/openstack/designate/blob/stable/ocata/designate/central/service.py#L2213

The designate charm hard-codes the notification_topics to "notifications_designate" (outgoing traffic)

https://git.io/vFMAP
notification_topics = notifications_designate

While per oslo.messaging the default is "notifications" which is overridden by that

https://github.com/openstack/oslo.messaging/blob/stable/ocata/oslo_messaging/notify/notifier.py#L49-L57

    cfg.ListOpt('topics',
                default=['notifications', ],
                deprecated_opts=[
                    cfg.DeprecatedOpt('topics',
                                      group='rpc_notifier2'),
                    cfg.DeprecatedOpt('notification_topics',
                                      group='DEFAULT')
                ],
                help='AMQP topic used for OpenStack notifications.'),
]

charm-ceilometer, OTOH, doesn't redefine anything like that, which is why not only dns.pool.update but other designate-related messages as well are not received by it - even those that are in event_definitions.yaml.

As I pasted above, there are also no event_definitions on the ceilometer side for dns.pool.* including dns.pool.update.

https://github.com/openstack/ceilometer/blob/stable/ocata/etc/ceilometer/event_definitions.yaml#L405-L435

The use-case may be event/audit logging but at least in this case we will solve the lack of other consumers.

AFAIKs, designate uses standard DNS protocol messages so any AMQP messages are rather for custom logic that could be implemented via ceilometer + aodh or pipelines in addition to event logging to panko https://docs.openstack.org/designate/pike/contributor/architecture.html#designate-minidns

For that reason I would add all possible emitted messages to event_definitions.yaml:

https://docs.openstack.org/designate/pike/admin/notifications.html#emitters

4. mdns -> DNS backend <- nothing to do here