openstack
/
kolla-ansible
Code Issues Proposed changes
Ansible deployment of the Kolla containers
12,726 Commits 6 Branches 91 Tags 160 MiB
Jinja 46.6%
Python 38.1%
Shell 15.1%
Ruby 0.2%
Go to file
Doug Szumski 6bfe1927f0 Remove classic queue mirroring for internal RabbitMQ 
When OpenStack is deployed with Kolla-Ansible, by default there
are no durable queues or exchanges created by the OpenStack
services in RabbitMQ. In Rabbit terminology, not being durable
is referred to as `transient`, and this means that the queue
is generally held in memory.

Whether OpenStack services create durable or transient queues is
traditionally controlled by the Oslo Notification config option:
`amqp_durable_queues`. In Kolla-Ansible, this remains set to
the default of `False` in all services. The only `durable`
objects are the `amq*` exchanges which are internal to RabbitMQ.

More recently, Oslo Notification has introduced support for
Quorum queues [7]. These are a successor to durable classic
queues, however it isn't yet clear if they are a good fit for
OpenStack in general [8].

For clustered RabbitMQ deployments, Kolla-Ansible configures all
queues as `replicated` [1]. Replication occurs over all nodes
in the cluster. RabbitMQ refers to this as 'mirroring of classic
queues'.

In summary, this means that a multi-node Kolla-Ansible deployment
will end up with a large number of transient, mirrored queues
and exchanges. However, the RabbitMQ documentation warns against
this, stating that 'For replicated queues, the only reasonable
option is to use durable queues: [2]`. This is discussed
further in the following bug report: [3].

Whilst we could try enabling the `amqp_durable_queues` option
for each service (this is suggested in [4]), there are
a number of complexities with this approach, not limited to:

1) RabbitMQ is planning to remove classic queue mirroring in
   favor of 'Quorum queues' in a forthcoming release [5].
2) Durable queues will be written to disk, which may cause
   performance problems at scale. Note that this includes
   Quorum queues which are always durable.
3) Potential for race conditions and other complexity
   discussed recently on the mailing list under:
   `[ops] [kolla] RabbitMQ High Availability`

The remaining option, proposed here, is to use classic
non-mirrored queues everywhere, and rely on services to recover
if the node hosting a queue or exchange they are using fails.
There is some discussion of this approach in [6]. The downside
of potential message loss needs to be weighed against the real
upsides of increasing the performance of RabbitMQ, and moving
to a configuration which is officially supported and hopefully
more stable. In the future, we can then consider promoting
specific queues to quorum queues, in cases where message loss
can result in failure states which are hard to recover from.

[1] https://www.rabbitmq.com/ha.html
[2] https://www.rabbitmq.com/queues.html
[3] https://github.com/rabbitmq/rabbitmq-server/issues/2045
[4] https://wiki.openstack.org/wiki/Large_Scale_Configuration_Rabbit
[5] https://blog.rabbitmq.com/posts/2021/08/4.0-deprecation-announcements/
[6] https://fuel-ccp.readthedocs.io/en/latest/design/ref_arch_1000_nodes.html#replication
[7] https://bugs.launchpad.net/oslo.messaging/+bug/1942933
[8] https://www.rabbitmq.com/quorum-queues.html#use-cases

Partial-Bug: #1954925
Change-Id: I91d0e23b22319cf3fdb7603f5401d24e3b76a56e
 		2022-02-21 18:54:04 +00:00
ansible Remove classic queue mirroring for internal RabbitMQ 2022-02-21 18:54:04 +00:00
contrib Update docs for Ubuntu 20.04 2020-11-20 08:40:36 +00:00
deploy-guide/source [docs] Unify project's naming convention 2021-01-27 20:08:41 +01:00
doc Merge "Add support for VMware First Class Disk (FCD)" 2022-02-21 11:07:00 +00:00
etc/kolla Merge "Add support for VMware First Class Disk (FCD)" 2022-02-21 11:07:00 +00:00
kolla_ansible Replace deprecated assertRaisesRegexp 2021-11-09 09:02:43 +08:00
releasenotes Remove classic queue mirroring for internal RabbitMQ 2022-02-21 18:54:04 +00:00
roles CI: Bump Ceph to Pacific 2022-02-10 12:15:54 +00:00
specs [docs] Unify project's naming convention 2021-01-27 20:08:41 +01:00
tests Merge "[CI] Filter fluentd errors more" 2022-02-11 10:02:16 +00:00
tools Merge "Add Ansible 5 aka core 2.12 support" 2022-01-20 20:53:03 +00:00
zuul.d Merge "[CI] Test Ironic on Debian" 2022-01-27 11:31:36 +00:00
.ansible-lint CI: Fix new ansible-lint failures 2022-02-15 07:42:53 +00:00
.gitignore Ignore .vscode/ in Git 2020-04-10 15:55:42 +02:00
.gitreview OpenDev Migration Patch 2019-04-19 19:29:02 +00:00
.stestr.conf Add custom filters for checking services 2019-09-16 12:48:52 +00:00
.yamllint Fix CI failures 2019-10-15 13:27:55 +01:00
CONTRIBUTING.rst [Community goal] Update the contributor guide 2020-05-20 17:55:57 +02:00
LICENSE Add ASL license 2014-09-20 17:29:35 -07:00
README.rst Drop vmtp 2021-12-21 07:29:32 +00:00
bindep.txt CI: Remove dbus from bindep and playbooks 2020-02-20 16:50:43 +00:00
requirements.txt Support storing passwords in Hashicorp Vault 2021-06-30 15:16:12 +01:00
setup.cfg Updating python testing classifier as per Yoga testing runtime 2022-02-16 14:59:40 +08:00
setup.py Cleanup py27 support 2020-04-26 12:16:44 +02:00
test-requirements.txt Add Ansible 5 aka core 2.12 support 2022-01-07 18:08:55 +00:00
tox.ini Refactor of kolla_docker into module_utils 2022-01-06 11:59:50 +01:00

README.rst

Kolla Ansible

image

The Kolla Ansible is a deliverable project separated from Kolla project.

Kolla Ansible deploys OpenStack services and infrastructure components in Docker containers.

Kolla's mission statement is:

To provide production-ready containers and deployment tools for operating
OpenStack clouds.

Kolla is highly opinionated out of the box, but allows for complete customization. This permits operators with little experience to deploy OpenStack quickly and as experience grows modify the OpenStack configuration to suit the operator's exact requirements.

Getting Started

Learn about Kolla Ansible by reading the documentation online Kolla Ansible.

Get started by reading the Developer Quickstart.

OpenStack services

Kolla Ansible deploys containers for the following OpenStack projects:

Infrastructure components

Kolla Ansible deploys containers for the following infrastructure components:

Directories

  • ansible - Contains Ansible playbooks to deploy OpenStack services and infrastructure components in Docker containers.
  • contrib - Contains demos scenarios for Heat, Magnum and Tacker and a development environment for Vagrant
  • doc - Contains documentation.
  • etc - Contains a reference etc directory structure which requires configuration of a small number of configuration variables to achieve a working All-in-One (AIO) deployment.
  • kolla_ansible - Contains password generation script.
  • releasenotes - Contains releasenote of all features added in Kolla Ansible.
  • specs - Contains the Kolla Ansible communities key arguments about architectural shifts in the code base.
  • tests - Contains functional testing tools.
  • tools - Contains tools for interacting with Kolla Ansible.
  • zuul.d - Contains project gate job definitions.

Getting Involved

Need a feature? Find a bug? Let us know! Contributions are much appreciated and should follow the standard Gerrit workflow.

  • We communicate using the #openstack-kolla irc channel.
  • File bugs, blueprints, track releases, etc on Launchpad.
  • Attend weekly meetings.
  • Contribute code.

Contributors

Check out who's contributing code and contributing reviews.

Notices

Docker and the Docker logo are trademarks or registered trademarks of Docker, Inc. in the United States and/or other countries. Docker, Inc. and other parties may also have trademark rights in other terms used herein.