cb48f7e5d2
Ansible failure handling is different when executing multiple top-level playbooks (CLI arguments) vs. multiple plays within a top-level playbook. If any hosts have failed or are unreachable at the end of a top-level playbook, then ansible-playbook exits non-zero. In contrast, execution will continue at the end of a mid-playbook play if there are hosts that have not failed or become unreachable. This is documented in [1]. Currently, Kayobe executes multiple top-level playbooks, most notably in the host configure commands where there is a long list of them. This has implications when working at scale, where failures are more common. If a host fails at any point, then execution of the command will stop at the end of the current playbook. This means that the command must be run again for all hosts. Additionally, if any hosts are unreachable, then the command is unable to progress at all without removing them from the inventory. This change refactors the host configure and host upgrade commands to use a single top-level playbook. [1] https://github.com/markgoddard/ansible-experiments/tree/master/14-error-handling Story: 2009854 Task: 44482 Change-Id: Ia63d66097b10b6ddda30ad693636143f8b1a85e0
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.