RabbitMQ container

See T583.

Definitions file should be saved somewhere to allow for configuration restore. (see new plan instead)

To run it, see T749.

rabbitmqadmin container

See T750.

New plan

RabbitMQ should be configured as code, not by restoring a definition file.

For the white-rabbit cluster, the following steps are needed:

• create administrator user from ops/secrets/nasqueron.white-rabbit.root, this one should be used by Salt (see bootstrap below)
• create vhosts
  • /
  • dev
• create exchanges
  • notifications (dev vhost, topic)
  • github-events (dev vhost, direct)
• create queues
  • wearg-notifications (dev vhost, bound to notifications exchange, routing key #)
• create users
  • notifications: ops/secrets/nasqueron.notifications.broker
  • wearg: apps/viperserv/broker
  • notifications-ysul: (not yet in Vault)
  • notifications-windriver: (not yet in Vault)
  • personal accounts for ops members who manage the cluster, for purge, etc.

Bootstrap the RabbitMQ account for Salt

1. In paas-docker role, for RabbitMQ container, create the account root, ensure admin user is removed:

set -e

docker exec -it {{ instance name }} rabbitmqctl add_user {{ username }} {{ password }}
docker exec -it {{ instance name }} rabbitmqctl set_user_tags {{ username }} administrator
{% for vhost in vhosts %}
docker exec -it {{ instance name }} rabbitmqctl set_permissions --vhost {{ vhost }} {{ username }} .* .* .*
{% endfor %}
docker exec -it {{ instance name }} rabbitmqctl delete_user administrator ; true
touch /srv/rabbitmq/{{ instance name }}/.root_account_created

Pitfalls:

• add_user returns 70 if the user exists -> not acceptable, exits through set -e (delete/recreate would also be acceptable)
• delete_user returns 67 if the user doesn't exist -> acceptable, so we can continue execution
• don't use set -x to avoid credentials in log

rabbitmq_{{ instance }}_administrator_account:
  cmd.script:
    - ...
    - creates: /srv/rabbitmq/{{ instance }}/.root_account_created

Option A:

2. On salt-primary role, save credentials in /usr/local/etc/salt/master.d/rabbitmq.conf (chmod 400)
3. Everything else can happens in a saas/rabbitmq role, with connections using saved configuration

Option B:

2. On salt-primary role, save instance credential path (e.g. ops/secrets/nasqueron.white-rabbit.root) in /usr/local/etc/salt/master.d/rabbitmq.conf
3. In saas/rabbitmq role, requires credentials from Vault each time

Option B is perfect for Nasqueron internal use, option A could be better if we maintain a RabbitMQ plugin.

General pitfalls:

• When a new vhost is created, the administrator root account needs access on it.