neutron-api charm creates notifications_designate queue in rabbitmq

It seems this is not severely impacting functionality so I'm going to mark move the importance to Medium. If this is not the case please add more details to the bug with respect to the impact.

It would be good to see which messages are actually in the queue.

See https://bugs.launchpad.net/charm-designate/+bug/1710831

Change abandoned by James Page (<email address hidden>) on branch: master
Review: https://review.openstack.org/433928
Reason: This problem will be resolved via the service-discovery specification planned for queens, avoiding the need to query the service catalog from a charm hook which tends to be racey and un-reliable during deployment.

Note reviews for pad.lv/1710831:

https://review.openstack.org/#/q/status:open%20topic:designate-notifications

I've added charm-rabbitmq-server project because a cronjob might be created to purge old messages until the "Service discovery" spec is out. Such cronjob should only be configured if is-leader.

Strange thing - the issue was solved in:

https://bugs.launchpad.net/charm-designate/+bug/1710831

but "notifications_designate" are still present in the code base:

https://github.com/openstack/charm-neutron-api/blob/master/hooks/neutron_api_context.py

So it looks like the "notifications_designate" were re-added in the following commit:

https://github.com/openstack/charm-neutron-api/commit/ff2547c6d552e85890c86d0677126ca1c09a9a04

as a part of discussion on bug 1738100.

The issue was fixed in the past by James Page as a part of Patch Set 7 for https://review.openstack.org/#/c/514629/7 :

$ cat openstack/charm-neutron-api / hooks/neutron_api_context.py
...
NOTIFICATION_TOPICS = [
    'notifications',
    'notifications_designate'
]

NOTIFICATION_TOPICS_DNS = [
    'notifications',
]
...
class NeutronAMQPContext(context.AMQPContext):
    '''AMQP context with Neutron API sauce'''

    def __init__(self):
        super(NeutronAMQPContext, self).__init__(ssl_dir=ETC_NEUTRON)

    def __call__(self):
        context = super(NeutronAMQPContext, self).__call__()
        if relation_ids('external-dns'):
            # Disable notifications_designate if designate dns
            # driver is going to be used.
            context['notification_topics'] = (
                ','.join(NOTIFICATION_TOPICS_DNS))
        else:
            context['notification_topics'] = (
                ','.join(NOTIFICATION_TOPICS))
        return context

It was removed later on as a part of Patch Set 12 which was merged.

What is the grand picture here actually?

I suppose the plan for the future is to drop this queue altogether from all charms (it's not only neutron-api that sets up this queue as far as I know) and use the plugin instead?
Or, only set up the queue if designate is related but do that consistently in all charms?

Is there a discussion happening somewhere? As I think this is a bit more general than just a neutron-api bug.

I suspect there is a number of deployments out there where this queue is constantly filled up as nobody is consuming it. (Any environment without designate basically)

Fix proposed to branch: master
Review: https://review.openstack.org/561918

Change abandoned by James Page (<email address hidden>) on branch: master
Review: https://review.openstack.org/561918