Juju Charm - RabbitMQ
Go to file
David Ames 2472e1ca9f Wait until clustered before running client hooks
RabbitMQ takes some time to fully cluster. The charm was previously
running amqp-relation-changed hooks whenever they were queued even
if the cluster was not yet complete. This led to split brain
scenarios. Client authentication to one or more nodes could fail.

This change confirms the entire cluster is ready before running
client amqp-relation-changed hooks.

min-cluster-size can now be used to attempt to guarantee the cluster
is ready with the expected number of nodes. If min-cluster-size is
not set the charm will still determine based on the information
available if all the cluster nodes are ready. Single node
deployments are still possible.

Partial-Bug: #1657245
Closes-Bug: #1657176
Change-Id: I870df71869c979e65a3a8764efdf35a746278507
2017-01-23 08:31:00 -08:00
actions Re-license charm as Apache-2.0 2016-07-01 18:06:36 +01:00
hooks Wait until clustered before running client hooks 2017-01-23 08:31:00 -08:00
lib Update tox.ini files from release-tools gold copy 2016-09-19 09:33:20 +01:00
scripts Changed the Nagios status when the queue data is not available from CRIT to UNKNOWN. 2015-12-02 08:38:33 +01:00
templates Enable cert files etc when ssl_mode is 'only' 2015-10-20 12:18:49 +01:00
tests Wait until clustered before running client hooks 2017-01-23 08:31:00 -08:00
unit_tests Wait until clustered before running client hooks 2017-01-23 08:31:00 -08:00
.coveragerc [wolson,r=jamespage,t=osci] Update restart logic around config-change hook to avoid extra restarts. 2015-01-22 15:37:28 +00:00
.gitignore Resync charm-helpers 2016-03-02 12:11:05 +00:00
.gitreview Add gitreview prior to migration to openstack 2016-02-24 21:53:36 +00:00
.project Added pydev project 2013-03-18 11:06:15 +00:00
.pydevproject Added pydev project 2013-03-18 11:06:15 +00:00
.testr.conf Add missing files 2016-02-16 07:52:08 +00:00
LICENSE Re-license charm as Apache-2.0 2016-07-01 18:06:36 +01:00
Makefile Use bundletester for amulet test execution 2016-07-21 17:58:15 +00:00
README.md Wait until clustered before running client hooks 2017-01-23 08:31:00 -08:00
actions.yaml Add pause/resume actions and sync charm-helpers 2016-04-05 18:52:37 +00:00
charm-helpers-hooks.yaml Update tox.ini files from release-tools gold copy 2016-09-19 09:33:20 +01:00
charm-helpers-tests.yaml Update tox.ini files from release-tools gold copy 2016-09-19 09:33:20 +01:00
config.yaml Add hardening support 2016-03-24 11:38:33 +00:00
copyright Re-license charm as Apache-2.0 2016-07-01 18:06:36 +01:00
hardening.yaml Add hardening support 2016-03-24 11:38:33 +00:00
icon.svg Added icon.svg 2013-04-25 14:23:14 -04:00
metadata.yaml Remove zesty series metadata 2016-12-03 09:48:33 -06:00
requirements.txt Fix pbr requirement 2016-04-13 10:25:23 +00:00
revision Added stats cronjob and queue monitoring nagios plugin 2014-05-07 10:52:24 +01:00
setup.cfg Create virtualenv to run unit tests 2015-01-19 15:02:29 -03:00
test-requirements.txt Use bundletester for amulet test execution 2016-07-21 17:58:15 +00:00
tox.ini Update tox.ini files from release-tools gold copy 2016-09-19 09:33:20 +01:00

README.md

Overview

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.

This charm deploys RabbitMQ server and provides AMQP connectivity to clients.

Usage

To deploy this charm:

juju deploy rabbitmq-server

deploying multiple units will form a native RabbitMQ cluster:

juju deploy -n 3 rabbitmq-server
juju config rabbitmq-server min-cluster-size=3

To make use of AMQP services, simply relate other charms that support the rabbitmq interface:

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

Clustering

When more than one unit of the charm is deployed the charm will bring up a native RabbitMQ cluster. The process of clustering the units together takes some time. Due to the nature of asynchronous hook execution it is possible client relationship hooks may be executed before the cluster is complete. In some cases, this can lead to client charm errors.

To guarantee client relation hooks will not be executed until clustering is completed use the min-cluster-size configuration setting:

juju deploy -n 3 rabbitmq-server
juju config rabbitmq-server min-cluster-size=3

When min-cluster-size is not set the charm will still cluster, however, there are no guarantees client relation hooks will not execute before it is complete.

Single unit deployments behave as expected.

Configuration: SSL

Generate an unencrypted RSA private key for the servers and a certificate:

openssl genrsa -out rabbit-server-privkey.pem 2048

Get an X.509 certificate. This can be self-signed, for example:

openssl req -batch -new -x509 -key rabbit-server-privkey.pem -out rabbit-server-cert.pem -days 10000

Deploy the service:

juju deploy rabbitmq-server

Enable SSL, passing in the key and certificate as configuration settings:

juju set rabbitmq-server ssl_enabled=True ssl_key="`cat rabbit-server-privkey.pem`" ssl_cert="`cat rabbit-server-cert.pem`"

Configuration: source

To change the source that the charm uses for packages:

juju set rabbitmq-server source="cloud:precise-icehouse"

This will enable the Icehouse pocket of the Cloud Archive (which contains a new version of RabbitMQ) and upgrade the install to the new version.

The source option can be used in a few different ways:

source="ppa:james-page/testing" - use the testing PPA owned by james-page
source="http://myrepo/ubuntu main" - use the repository located at the provided URL

The charm also supports use of arbitary archive key's for use with private repositories:

juju set rabbitmq-server key="C6CEA0C9"

Note that in clustered configurations, the upgrade can be a bit racey as the services restart and re-cluster; this is resolvable using (with Juju version < 2.0) :

juju resolved --retry rabbitmq-server/1

Or using the following command with Juju 2.0 and above:

juju resolved rabbitmq-server/1

Network Spaces support

This charm supports the use of Juju Network Spaces, allowing the charm to be bound to network space configurations managed directly by Juju. This is only supported with Juju 2.0 and above.

The amqp relation can be bound to a specific network space, allowing client connections to be routed over specific networks:

juju deploy rabbitmq-server --bind "amqp=internal-space"

alternatively this can also be provided as part of a juju native bundle configuration:

rabbitmq-server:
  charm: cs:xenial/rabbitmq-server
  num_units: 1
  bindings:
    amqp: internal-space

NOTE: Spaces must be configured in the underlying provider prior to attempting to use them.

NOTE: Existing deployments using the access-network configuration option will continue to function; this option is preferred over any network space binding provided if set.

Contact Information

Author: OpenStack Charmers openstack-charmers@lists.ubuntu.com Bugs: http://bugs.launchpad.net/charms/+source/rabbitmq-server/+filebug Location: http://jujucharms.com/rabbitmq-server