Deployment of containerised OpenStack to bare metal using kolla and bifrost
2071dc9a38
Kayobe has fairly coarse-grained default groups - controller, compute, etc, which work well in the majority of cases. Kolla Ansible allows much more fine-grained placement on a per-service basis, e.g. ironic-conductor. If the operator has taken advantage of this fine-grained placement, then it is possible that some of the assumptions in Kayobe may be incorrect. This is one downside of the split between Kayobe and Kolla Ansible. For example, Ironic conductor services may have been moved to a subset of the top level 'controllers' group. In this case, we would not want the Ironic networks to be mapped to all hosts in the controllers group - only those running Ironic conductor services. The same argument can be made if the loadbalancer services (HAProxy & keepalived) or Neutron dataplane services (e.g. L3 & DHCP agents) have been separated from the top level 'network' group. This change abstracts the placement of Ironic conductor Ironic inspector, loadbalancer and network services into separate variables, rather than referencing the top level 'controllers' and 'network' groups directly. These variables may be updated by the operator to match the service placement. Change-Id: Idbf181c795ee98ad653f11ae483f9dab4ef1b599 |
||
|---|---|---|
| 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 monitoring using Prometheus and Grafana.
- Log aggregation using OpenSearch and OpenSearch Dashboards.
Documentation
https://docs.openstack.org/kayobe/latest/
Release Notes
https://docs.openstack.org/releasenotes/kayobe/
Bugs
https://bugs.launchpad.net/kayobe
Community
OFTC's IRC channel: #openstack-kolla
License
Kayobe is distributed under the Apache 2.0 License.