22a6223b1b
After all of the discussions we had on "https://review.opendev.org/#/c/670626/2", I studied all projects that have an "oslo_messaging" section. Afterwards, I applied the same method that is already used in "oslo_messaging" section in Nova, Cinder, and others. This guarantees that we have a consistent method to enable/disable notifications across projects based on components (e.g. Ceilometer) being enabled or disabled. Here follows the list of components, and the respective changes I did. * Aodh: The section is declared, but it is not used. Therefore, it will be removed in an upcomming PR. * Congress: The section is declared, but it is not used. Therefore, it will be removed in an upcomming PR. * Cinder: It was already properly configured. * Octavia: The section is declared, but it is not used. Therefore, it will be removed in an upcomming PR. * Heat: It was already using a similar scheme; I just modified it a little bit to be the same as we have in all other components * Ceilometer: Ceilometer publishes some messages in the rabbitMQ. However, the default driver is "messagingv2", and not ''(empty) as defined in Oslo; these configurations are defined in ceilometer/publisher/messaging.py. Therefore, we do not need to do anything for the "oslo_messaging_notifications" section in Ceilometer * Tacker: It was already using a similar scheme; I just modified it a little bit to be the same as we have in all other components * Neutron: It was already properly configured. * Nova It was already properly configured. However, we found another issue with its configuration. Kolla-ansible does not configure nova notifications as it should. If 'searchlight' is not installed (enabled) the 'notification_format' should be 'unversioned'. The default is 'both'; so nova will send a notification to the queue versioned_notifications; but that queue has no consumer when 'searchlight' is disabled. In our case, the queue got 511k messages. The huge amount of "stuck" messages made the Rabbitmq cluster unstable. https://bugzilla.redhat.com/show_bug.cgi?id=1478274 https://bugs.launchpad.net/ceilometer/+bug/1665449 * Nova_hyperv: I added the same configurations as in Nova project. * Vitrage It was already using a similar scheme; I just modified it a little bit to be the same as we have in all other components * Searchlight I created a mechanism similar to what we have in AODH, Cinder, Nova, and others. * Ironic I created a mechanism similar to what we have in AODH, Cinder, Nova, and others. * Glance It was already properly configured. * Trove It was already using a similar scheme; I just modified it a little bit to be the same as we have in all other components * Blazar It was already using a similar scheme; I just modified it a little bit to be the same as we have in all other components * Sahara It was already using a similar scheme; I just modified it a little bit to be the same as we have in all other components * Watcher I created a mechanism similar to what we have in AODH, Cinder, Nova, and others. * Barbican I created a mechanism similar to what we have in Cinder, Nova, and others. I also added a configuration to 'keystone_notifications' section. Barbican needs its own queue to capture events from Keystone. Otherwise, it has an impact on Ceilometer and other systems that are connected to the "notifications" default queue. * Keystone Keystone is the system that triggered this work with the discussions that followed on https://review.opendev.org/#/c/670626/2. After a long discussion, we agreed to apply the same approach that we have in Nova, Cinder and other systems in Keystone. That is what we did. Moreover, we introduce a new topic "barbican_notifications" when barbican is enabled. We also removed the "variable" enable_cadf_notifications, as it is obsolete, and the default in Keystone is CADF. * Mistral: It was hardcoded "noop" as the driver. However, that does not seem a good practice. Instead, I applied the same standard of using the driver and pushing to "notifications" queue if Ceilometer is enabled. * Cyborg: I created a mechanism similar to what we have in AODH, Cinder, Nova, and others. * Murano It was already using a similar scheme; I just modified it a little bit to be the same as we have in all other components * Senlin It was already using a similar scheme; I just modified it a little bit to be the same as we have in all other components * Manila It was already using a similar scheme; I just modified it a little bit to be the same as we have in all other components * Zun The section is declared, but it is not used. Therefore, it will be removed in an upcomming PR. * Designate It was already using a similar scheme; I just modified it a little bit to be the same as we have in all other components * Magnum It was already using a similar scheme; I just modified it a little bit to be the same as we have in all other components Closes-Bug: #1838985 Change-Id: I88bdb004814f37c81c9a9c4e5e491fac69f6f202 Signed-off-by: Rafael Weingärtner <rafael@apache.org>
Team and repository tags
Kolla-Ansible Overview
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:
- Aodh
- Barbican
- Bifrost
- Blazar
- Ceilometer
- Cinder
- CloudKitty
- Congress
- Cyborg
- Designate
- Freezer
- Glance
- Heat
- Horizon
- Ironic
- Karbor
- Keystone
- Kuryr
- Magnum
- Manila
- Mistral
- Monasca
- Murano
- Neutron
- Nova
- Octavia
- Panko
- Qinling
- Rally
- Sahara
- Searchlight
- Senlin
- Solum
- Swift
- Tacker
- Tempest
- Trove
- Vitrage
- Vmtp
- Watcher
- Zun
Infrastructure components
Kolla-Ansible deploys containers for the following infrastructure components:
- Ceph implementation for Cinder, Glance and Nova.
- Collectd, Telegraf, InfluxDB, Prometheus, and Grafana for performance monitoring.
- Elasticsearch and Kibana to search, analyze, and visualize log messages.
- Etcd a distributed reliable key-value store.
- Fluentd as an open source data collector for unified logging layer.
- Gnocchi A time-series storage database.
- HAProxy and Keepalived for high availability of services and their endpoints.
- MariaDB and Galera Cluster for highly available MySQL databases.
- Memcached a distributed memory object caching system.
- MongoDB as a database back end for Panko.
- Open vSwitch and Linuxbridge backends for Neutron.
- RabbitMQ as a messaging backend for communication between services.
- Redis an in-memory data structure store.
- Zookeeper an open-source server which enables highly reliable distributed coordination.
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 Vagrantdoc- 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.