Juju Charm - RabbitMQ
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Zuul 622bff7aa1 Merge "Reflect recent test.yaml changes in osci.yaml" 5 days ago
actions Implementation of deferred restarts 2 months ago
charmhelpers c-h sync - restore proxy env vars for add-apt-repository 1 month ago
files Merge "Fix: do not use charmhelpers in non-charm context" 5 months ago
hooks Implementation of deferred restarts 2 months ago
lib Update tox.ini files from release-tools gold copy 5 years ago
templates Add queue-master-locator config option 6 months ago
tests Test bundles for focal-wallaby and hirsute-wallaby 1 month ago
unit_tests Implementation of deferred restarts 2 months ago
.gitignore Forget cluster node as an action 1 year ago
.gitreview OpenDev Migration Patch 2 years ago
.stestr.conf Fix lint in unit tests re: py3-first and py2 compat 3 years ago
.zuul.yaml NRPE: Allow excluding queues from queue-size checks 5 months ago
LICENSE Re-license charm as Apache-2.0 5 years ago
Makefile Port Charm RabbitMQ func tests from Amulet to Zaza 2 years ago
README.md Clarify TLS 4 months ago
actions.yaml Implementation of deferred restarts 2 months ago
charm-helpers-hooks.yaml Updates to flip all libraries back to master 1 month ago
config.yaml Implementation of deferred restarts 2 months ago
copyright Re-license charm as Apache-2.0 5 years ago
hardening.yaml Add hardening support 5 years ago
icon.svg Added icon.svg 8 years ago
metadata.yaml Add impish to metadata.yaml 1 week ago
osci.yaml Reflect recent test.yaml changes in osci.yaml 3 months ago
requirements.txt Sync release-tools 6 months ago
revision Added stats cronjob and queue monitoring nagios plugin 7 years ago
setup.cfg Add Python 3 Train unit tests 2 years ago
test-requirements.txt Updates to flip all libraries back to master 1 month ago
tox.ini Sync release-tools 6 months ago



RabbitMQ is an implementation of AMQP, the emerging standard for high performance enterprise messaging. The RabbitMQ server is a robust and scalable implementation of an AMQP broker.

The rabbitmq-server charm deploys RabbitMQ server and provides AMQP services to those charms that support the rabbitmq interface. The current list of such charms can be obtained from the Charm Store (the charms officially supported by the OpenStack Charms project are published by 'openstack-charmers').



This section covers common and/or important configuration options. See file config.yaml for the full list of options, along with their descriptions and default values. See the Juju documentation for details on configuring applications.


The min-cluster-size option sets the number of rabbitmq-server units required to form its cluster. It is best practice to use this option as doing so ensures that the charm will wait until the cluster is up before accepting relations from other client applications.


The source option sets an alternate software source and can be passed during or after deployment. The default behaviour is to use the Ubuntu package archive for the underlying machine series. The most common value is a UCA cloud pocket (e.g. 'cloud:bionic-train'). In the case of a non-OpenStack project, there is no guarantee that a candidate will be found in the stated UCA pocket.

Note: Changing the value of this option post-deployment will trigger a software upgrade. See OpenStack upgrade in the OpenStack Charms Deployment Guide.


To deploy a single rabbitmq-server unit:

juju deploy rabbitmq-server

To make use of AMQP services, simply add a relation between rabbitmq-server and an application that supports the rabbitmq interface. For instance:

juju add-relation rabbitmq-server:amqp nova-cloud-controller:amqp

High availability

When more than one unit is deployed the charm will bring up a native RabbitMQ HA active/active cluster. The min-cluster-size option should be used (see description above).

See Infrastructure high availability in the OpenStack Charms Deployment Guide for details.


Communication between the AMQP message queue and client services (OpenStack applications) can be TLS-encrypted. There are two methods for managing keys and certificates:

  1. with Vault
  2. manually (via charm options)

Vault can set up private keys and server certificates for an application. It also stores a central CA certificate for the cloud. See the vault charm for more information.

Vault is the recommended method and is what will be covered here.

The private key and server certificate (and its signing) are managed via a relation made to the vault application:

juju add-relation rabbitmq-server:certificates vault:certificates


This section lists Juju actions supported by the charm. Actions allow specific operations to be performed on a per-unit basis.

  • check-queues
  • cluster-status
  • complete-cluster-series-upgrade
  • list-unconsumed-queues
  • pause
  • resume

To display action descriptions run juju actions --schema rabbitmq-server. If the charm is not deployed then see file actions.yaml.


The OpenStack Charms project maintains two documentation guides:


For general charm questions refer to the OpenStack Charm Guide.