# Versions
rabbitmq-server, rev 61
We have a few openstack deployments without ceilometer where there are rabbitmq queues (notifications.error, notifications.info, notifications_designate.info) that are endlessly filling up. I'm guessing this is because there is no ceilometer instance to consume these queues.
As far as I can tell these are some of the ways to work around this, either set TTL's or max queue sizes on the rabbitmq queues, or tell the different openstack services to not report to rabbitmq by changing the notification_driver to noop.
All in all, this makes for a not so fun default behaviour as it also impacts the default nrpe rabbitmq_queue checks.
# Our current workaround
Set the message TTL to 10 min for all queues with name starting with notifications for the rabbitmq vhost called openstack (default).
rabbitmqctl set_policy TTL "notifications*" '{"message-ttl":600000}' --priority 1 --apply-to queues -p openstack
Purge the messages already in the queue as they won't be cleared by the new TTL
rabbitmqctl purge_queue notifications.error -p openstack
rabbitmqctl purge_queue notifications.info -p openstack
rabbitmqctl purge_queue notifications_designate.info -p openstack
I think setting the TTL policy is an OK workaround; note that this type of reconfiguration in the event that ceilometer is or is not deployed would be covered by the service discovery spec (which although specified remains unimplemented to date).
[0] http:// specs.openstack .org/charm- specs/specs/ queens/ approved/ service- discovery. html