Deployment of containerised OpenStack to bare metal using kolla and bifrost
6496cfc0ba
In a deployment that has both Ceph or Swift deployed it can be useful to seperate the network traffic. This change adds support for dedicated storage networks for both Ceph and Swift. By default, the storage hosts are attached to the following networks: * Overcloud admin network * Internal network * Storage network * Storage management network This adds four additional networks, which can be used to seperate the storage network traffic as follows: * Ceph storage network (ceph_storage_net_name) is used to carry Ceph storage data traffic. Defaults to the storage network (storage_net_name). * Ceph storage management network (ceph_storage_mgmt_net_name) is used to carry storage management traffic. Defaults to the storage management network (storage_mgmt_net_name). * Swift storage network (swift_storage_net_name) is used to carry Swift storage data traffic. Defaults to the storage network (storage_net_name). * Swift storage replication network (swift_storage_replication_net_name) is used to carry storage management traffic. Defaults to the storage management network (storage_mgmt_net_name). This change also includes several improvements to Swift device management and ring generation. The device management and ring generation are now separate, with device management occurring during 'kayobe overcloud host configure', and ring generation during a new command, 'kayobe overcloud swift rings generate'. For the device management, we now use standard Ansible modules rather than commands for device preparation. File system labels can be configured for each device individually. For ring generation, all commands are run on a single host, by default a host in the Swift storage group. A python script runs in one of the kolla Swift containers, which consumes an autogenerated YAML config file that defines the layout of the rings. Change-Id: Iedc7535532d706f02d710de69b422abf2f6fe54c |
||
|---|---|---|
| .github | ||
| ansible | ||
| dev | ||
| doc | ||
| etc/kayobe | ||
| kayobe | ||
| playbooks | ||
| releasenotes | ||
| roles | ||
| tools | ||
| zuul.d | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .travis.yml | ||
| .yamllint | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| 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.
- Free software: Apache license
- Documentation: https://kayobe.readthedocs.io/en/latest/
- Source: https://git.openstack.org/cgit/openstack/kayobe
- Bugs: https://storyboard.openstack.org/#!/project/openstack/kayobe
- Release Notes: https://kayobe-release-notes.readthedocs.io/en/latest/
- IRC: #openstack-kayobe
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
In the near future we aim to add support for the following:
- Control plane and workload monitoring and log aggregation using OpenStack monasca