cc4150292c
enable_rabbitmq_cluster is now a "yes" by default but you can set it to "no" if you want to disable clustering under any circumstances. The agreement made at OpenStack in Austin was that Kolla-Kubernetes would concentrate on RabbitMQ and MariaDB without clustering but with persistent storage and workload migration, then examine how to do proper distributed functionality as the project progresses, so I am just following what we'd already agreed upon. First, it helps us deal with issues of version upgrades without dealing with clustered version upgrades and the synchronization thereof. Second, it provides an alternative model for durability when used in Kubernetes. Understand that, if we disable RabbitMQ's clustering, Kubernetes is still able to re-schedule the queue off of a failed node in ways that Kolla-Ansible is not. There are known issues with RabbitMQ clustering, especially with auto-heal turned on. For many small-to-mid-sized clusters, it's going to provide for a better operator experience to have the known potential for a 30 second blip after RabbitMQ node failure than it is to have the known potential for partition and data loss and/or manual operations after you've turned off auto-heal. Kolla-kubernetes has already turned off host networking for the RabbitMQ pod; it's safe to set the interface address in the Kubernetes context. The question was asked why don't I just set the RabbitMQ cluster to be a single instance. It's unlikely that Kubernetes RabbitMQ with a PetSet will be clustered in the same declaritive fashion as the rabbitmq-clusterer plugin. Easier to just disable it and worry about how to configure the kube-friendly clustered RabbitMQ at a later point in time. Furthermore, it's an entirely valid case for many OpenStack control planes hosted atop Kolla-Kubernetes to accept the possibility of a 30-60 second blip in lieu of the long and questionable history of RabbitMQ clustering in production. Co-authored-by: Ryan Hallisey <rhallise@redhat.com> Change-Id: I7f0cb22d29a418fce4af8d69f63739859173d746 Partially-implements: blueprint api-interface-bind-address-override |
||
|---|---|---|
| ansible | ||
| demos | ||
| dev | ||
| doc | ||
| docker | ||
| etc | ||
| kolla | ||
| releasenotes | ||
| specs | ||
| tests | ||
| tools | ||
| .gitignore | ||
| .gitreview | ||
| .testr.conf | ||
| LICENSE | ||
| loc | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
Kolla Overview
The Kolla project is a member of the OpenStack Big Tent Governance. Kolla's mission statement is:
Kolla provides production-ready containers and deployment tools for
operating OpenStack clouds.Kolla provides Docker containers and Ansible playbooks to meet Kolla's mission. 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 by reading the documentation online docs.openstack.org.
Get started by reading the Developer Quickstart.
Kolla provides images to deploy the following OpenStack projects:
- Aodh
- Ceilometer
- Cinder
- Designate
- Glance
- Gnocchi
- Heat
- Horizon
- Ironic
- Keystone
- Magnum
- Manila
- Mistral
- Murano
- Nova
- Neutron
- Swift
- Tempest
- Trove
- Zaqar
As well as these infrastructure components:
- Ceph implementation for Cinder, Glance and Nova
- Openvswitch and Linuxbridge backends for Neutron
- MongoDB as a database backend for Ceilometer and Gnocchi
- RabbitMQ as a messaging backend for communication between services.
- HAProxy and Keepalived for high availability of services and their endpoints.
- MariaDB and Galera for highly available MySQL databases
- Heka A distributed and scalable logging system for openstack services.
Docker Images
The Docker images are built by the Kolla project maintainers. A detailed process for contributing to the images can be found in the image building guide.
The Kolla developers build images in the kolla namespace for every tagged release and implement an Ansible deployment for many but not all of them.
You can view the available images on Docker Hub or with the Docker CLI:
$ sudo docker search kollaDirectories
- ansible - Contains Ansible playbooks to deploy Kolla in Docker containers.
- demos - Contains a few demos to use with Kolla.
- dev/heat - Contains an OpenStack-Heat based development environment.
- dev/vagrant - Contains a vagrant VirtualBox/Libvirt based development environment.
- 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.
- docker - Contains jinja2 templates for the docker build system.
- tools - Contains tools for interacting with Kolla.
- specs - Contains the Kolla communities key arguments about architectural shifts in the code base.
- tests - Contains functional testing tools.
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.