d8fe3ea780
Certain services such as Murano and trove require access to a rabbitmq instance from tenant networks. [0] Exposing the internal rabbitmq to end users is a security hole, hence there are two options, 1) use vhosts in the existing rabbitmq, or two a separate rabbitmq instances. Given the importance of rabbitmq to the OpenStack deployment, we have decided to go with a separate instance. Refer to [1] for more detail on the various options. This change makes the rabbitmq role generic so that it can be reused, in this case to start 'outward_rabbitmq'. It needs to be exposed via haproxy both for network isolation and also because this is what Murano configuration requires. Follow on patches will be added to add a vhost in this outward instance for Murano and other services which require access. Based on the original work by bdaca[2] [0] http://murano.readthedocs.io/en/stable-liberty/intro/architecture.html [1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109091.html [2] https://review.openstack.org/#/c/374525 Change-Id: Ib2bcc7ed4bf4f883a7cd1dfad3db89201e3cfd8d Partial-Bug: #1620374 Depends-On: I020eb6219f89a310451becde41f6f1c7f54baadd Co-Authored-By: Bartłomiej Daca <bartek.daca@gmail.com>
6 lines
143 B
YAML
6 lines
143 B
YAML
---
|
|
features:
|
|
- Add a new 'outward facing' rabbitmq, for services
|
|
which require a user facing message queue such as
|
|
Murano or Trove.
|