d277323b3e
In many cases we use the kolla_address filter to look up the IP address of the current host or another host on a particular network interface. This filter uses the host's facts to determine the IP, meaning that we must have gathered facts for the host, even if it is outside of a requested --limit. This is a limitation, since it requires that all hosts must be reachable, even if we are not directly configuring them. Most instances of this cross-host fact referencing involve a controller, since they host clustered services. The only instance found to affect compute nodes is in the prometheus role, where Prometheus server needs to know the IP address of all targets in its scrape configs. If we are able to specify the address of the scrape targets as a static variable such as a host variable, then facts would not be required for compute nodes outside of the --limit. Removing the requirement to have facts for all compute nodes has benefits for performance (gathering facts for all hosts can take a long time) and fault tolerance (we can operate when some compute hosts are unreachable). This change modifies the kolla_address filter to accept an optional override_var argument which can be used to specify the name of a host variable that may override the returned IP address. This is used in the Prometheus server configuration to allow specifying the IP address used by Prometheus server when collecting metrics from exporter using a 'prometheus_target_address' host variable. If specified, this takes precedence over the API interface address currently used. This makes it possible to statically override prometheus_target_address and avoid the cross-host fact reference. This is not a complete solution because it is not yet possible to skip the cross-host fact gathering step. Partial-Bug: #2041860 Change-Id: I207ca56362de00d8ec578333eab9e1a72e7bcd19
Kolla Ansible
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
- Cyborg
- Designate
- Glance
- Heat
- Horizon
- Ironic
- Keystone
- Kuryr
- Magnum
- Manila
- Masakari
- Mistral
- Neutron
- Nova
- Octavia
- Skyline (APIServer and Console)
- Swift
- Tacker
- Trove
- Venus
- Watcher
- Zun
Infrastructure components
Kolla Ansible deploys containers for the following infrastructure components:
- Collectd, Telegraf, InfluxDB, Prometheus, and Grafana for performance monitoring.
- OpenSearch and OpenSearch Dashboards 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.
- Open vSwitch for use with Neutron.
- RabbitMQ as a messaging backend for communication between services.
- Redis an in-memory data structure store.
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.