neutron-api charm creates notifications_designate queue in rabbitmq

[Aymen Frikha]

In template of (neutron.conf) in neutron-api charm we have this configuration:

notification_topics = notifications,notifications_designate

this allows neutron-server to create notification_designate.info queue in rabbitmq even if designate is not deployed with neutron-api.
The result of this, is we have a queue in rabbitmq that contains a lot of messages that are not consumed by anyone.

[Corey Bryant (corey.bryant)]

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.

[Dmitrii Shcherbakov (dmitriis)]

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

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

[OpenStack Infra (hudson-openstack)]

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.

[Dmitrii Shcherbakov (dmitriis)]

Note reviews for pad.lv/1710831:

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

[Alvaro Uria (aluria)]

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.

[Tytus Kurek (tkurek)]

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

[Tytus Kurek (tkurek)]

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.

[Tytus Kurek (tkurek)]

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.

[Tilman Baumann (tilmanbaumann)]

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)

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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