Deployment of containerised OpenStack to bare metal using kolla and bifrost
af3b719b73
The group variables originally in ansible/group_vars/ were playbook group variables, due to being adjacent to the playbooks. Typically they provided default values for global variables in the all group, as well as some more specific groups. This has worked fairly well, but results in (at least) a couple of problems. 1. The default variable precedence rules mean that these playbook group variables have a higher precedence than inventory group variables (for a given group). This can make it challenging to override playbook group variables in the inventory in Kayobe configuration. 2. Any playbook run by Kayobe must be in the same directory as the playbook group variables in order to use them. Given that they include variables required for connectivity such as ansible_host and ansible_user, this is quite critical. For Kayobe custom playbooks, we work around this by symlinking to the group_vars directory from the directory containing the custom playbook. This is not an elegant workaround, and has assumptions about the relative paths of the Kayobe configuration and virtual environment in which Kayobe is installed. Story: 2010280 Task: 46233 Change-Id: Ifea5c7e73f6f410f96a7398bfd349d1f631d9fc0 |
||
|---|---|---|
| ansible | ||
| dev | ||
| doc | ||
| etc/kayobe | ||
| kayobe | ||
| playbooks | ||
| releasenotes | ||
| roles | ||
| tools | ||
| zuul.d | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .yamllint | ||
| bindep.txt | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| molecule-requirements.txt | ||
| README.rst | ||
| requirements.txt | ||
| requirements.yml | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
| Vagrantfile | ||
Kayobe
Kayobe enables deployment of containerised OpenStack to bare metal.
Containers offer a compelling solution for isolating OpenStack services, but running the control plane on an orchestrator such as Kubernetes or Docker Swarm adds significant complexity and operational overheads.
The hosts in an OpenStack control plane must somehow be provisioned, but deploying a secondary OpenStack cloud to do this seems like overkill.
Kayobe stands on the shoulders of giants:
- OpenStack bifrost discovers and provisions the cloud
- OpenStack kolla builds container images for OpenStack services
- OpenStack kolla-ansible delivers painless deployment and upgrade of containerised OpenStack services
To this solid base, kayobe adds:
- Configuration of cloud host OS & flexible networking
- Management of physical network devices
- A friendly openstack-like CLI
All this and more, automated from top to bottom using Ansible.
Features
- Heavily automated using Ansible
- kayobe Command Line Interface (CLI) for cloud operators
- Deployment of a seed VM used to manage the OpenStack control plane
- Configuration of physical network infrastructure
- Discovery, introspection and provisioning of control plane hardware using OpenStack bifrost
- Deployment of an OpenStack control plane using OpenStack kolla-ansible
- Discovery, introspection and provisioning of bare metal compute hosts using OpenStack ironic and ironic inspector
- Virtualised compute using OpenStack nova
- Containerised workloads on bare metal using OpenStack magnum
- Big data on bare metal using OpenStack sahara
- Control plane and workload monitoring and log aggregation using OpenStack monasca
Documentation
https://docs.openstack.org/kayobe/latest/
Release Notes
https://docs.openstack.org/releasenotes/kayobe/
Bugs
https://storyboard.openstack.org/#!/project/openstack/kayobe
Community
OFTC's IRC channel: #openstack-kolla
License
Kayobe is distributed under the Apache 2.0 License.