Mark Goddard 7bcc5579e2 Fix seed VM interface ordering
Currently the ordering of network interfaces in the seed VM is
non-deterministic. This happens because we apply the 'unique' filter to
the network_interfaces list, which does not guarantee a deterministic
ordering. This list is then transformed and passed to the
stackhpc.libvirt-vm role.

There are two consequences of this:

* it is not possible to determine which interface names should be used
  prior to creating a seed VM
* if a seed VM is recreated, the interface ordering may change

This change fixes the issue by sorting the network_interfaces list
alphabetically before it is transformed and passed to the
stackhpc.libvirt-vm.

A new 'seed_vm_interfaces' variable is also added, which allows for
customisation of the VM's interfaces - potentially allowing for more
complex setups such as trunked VLANs.

Story: 2007259
Task: 38621

There is a second issue, which is that if the seed VM has a
network interface not configured with a gateway, cloud-init will fail to
configure the network interfaces on the host. This has been observed on
CentOS 8, but is probably more tied to the version of cloud-init, and
may affect CentOS 7. The following error is seen in the cloud-init logs:

    KeyError: 'gateway'

This change has been addressed in the jriguera.configdrive role, and
this change updates the version used in requirements.yml.

Story: 2007769
Task: 39993

Change-Id: Ib6ab41a3ba320a1fe15d0d23561fad2fab7861e6
2020-06-12 17:32:48 +01:00
2017-12-14 20:39:55 +00:00
2020-06-12 17:32:48 +01:00
2020-06-12 17:32:48 +01:00
2020-06-02 20:19:56 +02:00
2020-05-29 15:42:07 +01:00
2019-09-16 16:26:27 +02:00
2019-06-25 02:24:45 +00:00
2017-04-06 10:15:29 +01:00
2020-05-12 19:04:43 +02:00
2020-04-20 18:04:19 +00:00
2020-05-29 15:42:07 +01:00
2020-05-19 10:08:36 +01:00

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
Description
Deployment of containerised OpenStack to bare metal using kolla and bifrost
Readme 39 MiB
Languages
Python 85.1%
Shell 8%
Jinja 6.9%