Initiative

Introduction

The first release of StarlingX provided a hardened OpenStack platform
Evolution plan to move to a cloud native (Kubernetes) platform was presented at the Vancouver Summit
- Run the infrastructure including OpenStack services as containerized applications on Kubernetes
- Containerization work is planned to be done in phases having OpenStack and dependencies the initial focus

Kubernetes master configuration on two nodes with high availability (HA)
- Run on existing StarlingX nodes
- Deployed by StarlingX system configuration
Calico CNI plugin
Docker runtime
CEPH as persistent storage backend
- Leverage existing bare metal CEPH cluster
- Extend CEPH support to one- and two-node configuration
Authentication/authorization of Kubernetes APIs with Keystone
Local Docker image registry, authentication with Keystone
Helm as package manager
Airship Armada for orchestrating the deployment of multiple Helm charts (ex. OpenStack)
Initial Kubernetes hosting environment for applications, the infrastructure including OpenStack will also be containerized

The "Flock" services with the exceptions called out later are not planned to be containerized for the initial phase
An instance of Keystone, RabbitMQ, and PostgreSQL will remain on bare metal and will be used for the "Flock" service
An instance of Horizon will remain on bare metal for the "Flock" services only

All OpenStack services currently integrated by StarlingX are planned to be containerized
- Including dependencies such as MariaDB
- Pike based
  - nova-api proxy from stx-nfv will be containerized
  - nova-compute will be containerized
  - Neutron will be containerized
  - cilometer-poller will be containerized
- Keystone container will run in the 'openstack' namespace for the OpenStack services only
rbd-provisioner pod: enabling pvc's from the CEPH cluster
An instance of the Fault Management service will be containerized for alarming in OpenStack
Current StarlingX compute nodes are re-purposed as Kubernetes worker nodes
OVS-DPDK is not containerized
- No Helm chart is currently available

OpenStack Helm to be used as a starting point
- Extensions are required (e.g. CentOS support) with the plan of working with the OpenStack Helm team upstream
- Airship Armada to orchestrate the set of Helm charts that comprise OpenStack
Extensions to the StarlingX Configuration Management service
- Generation of Helm chart overrides
- Kubernetes node label assignments
- Upload application
  - Push images to local docker registry
  - Install Helm charts and Armada manifests
- Install application
  - Interface with Configuration Management for override generation and invoking Armada to deploy
- Update application
  - Allow the end user to specify overrides to particular charts and the trigger an update via Armada

The build system will have to be enhanced to generate StarlingX based Docker images for the containerized services
Images would be hosted on a public repository