Merge "Spec for system deployment of containerized openstack infrastructure"
This commit is contained in:
Zuul
Gerrit Code Review
commit
606c09eab8
@ -0,0 +1,276 @@
|
||||
===========================================================
|
||||
System Deployment of Containerized OpenStack Infrastructure
|
||||
===========================================================
|
||||
|
||||
Storyboard: https://storyboard.openstack.org/#!/story/2003910
|
||||
|
||||
This story will update StarlingX to deploy its OpenStack infrastructure in a
|
||||
containerized configuration. Changes will be identified and implemented to
|
||||
enable end-to-end configuration of all the containers that will host
|
||||
OpenStack infrastructure services.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Please see the following for background on the effort to containerize the
|
||||
StartlingX OpenStack infrastructure:
|
||||
https://wiki.openstack.org/wiki/Containerizing_StarlingX_Infrastructure
|
||||
|
||||
This story implements the end-to-end configuration of the StarlingX
|
||||
platform with the OpenStack infrastructure services running in containers.
|
||||
It builds on several other stories which are listed in the Dependencies
|
||||
section below.
|
||||
|
||||
Use Cases
|
||||
=========
|
||||
|
||||
Developers/testers/users need the ability to install and configure a StarlingX
|
||||
system with kubernetes master and worker nodes, in order to support a
|
||||
variety of containerized applications.
|
||||
|
||||
Developers/testers/users need the ability to install and configure the
|
||||
OpenStack application on a running StarlingX system.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
The initial install of a StarlingX system will no longer include the OpenStack
|
||||
software (with the exception of Keystone and Horizon which are required by
|
||||
bare metal platform services). The OpenStack application will have its own
|
||||
instance of Keystone and Horizon.
|
||||
|
||||
To install the OpenStack application, the user will first label the hosts to
|
||||
be used for OpenStack controller functions (label: openstack-controller-node)
|
||||
and OpenStack compute functions (label: openstack-compute-node) using the
|
||||
following CLI:
|
||||
|
||||
system host-label-assign <hostname> <label>
|
||||
|
||||
Then the user will use the following CLI to import the OpenStack application:
|
||||
|
||||
system application-upload <app-name> <app-tarfile>
|
||||
|
||||
Finally, the user will install the OpenStack application:
|
||||
|
||||
system application-install <app-name>
|
||||
|
||||
The above CLIs are created as part of the stories listed in the Dependencies
|
||||
section below (see the Armada Integration story for details). This story
|
||||
provides the "glue" that performs the necessary configuration of platform
|
||||
services (e.g. System Inventory (sysinv), Virtual Infrastructure Manager
|
||||
(VIM)) to support the OpenStack application.
|
||||
|
||||
Alternatives
|
||||
============
|
||||
|
||||
This is the only reasonable approach to integrate the containerized OpenStack
|
||||
application with the StartlingX platform.
|
||||
|
||||
Data model impact
|
||||
=================
|
||||
|
||||
None - any data model impacts are described in the stories listed in the
|
||||
Dependencies section below.
|
||||
|
||||
REST API impact
|
||||
===============
|
||||
|
||||
None - any REST API impacts are described in the stories listed in the
|
||||
Dependencies section below.
|
||||
|
||||
Security impact
|
||||
===============
|
||||
|
||||
This story does not expose any new interfaces to the external world. Any
|
||||
security impacts are described in stories listed in the Dependencies section
|
||||
below.
|
||||
|
||||
Other end user impact
|
||||
=====================
|
||||
|
||||
Prior to this story, all StarlingX systems would come up with the OpenStack
|
||||
services installed by default (on bare metal) after initial system
|
||||
configuration.
|
||||
|
||||
After this story, all StarlingX systems will come up without the OpenStack
|
||||
services. If a user wants to install the OpenStack application
|
||||
(containerized), they will perform the actions described in the Proposed
|
||||
Change section above.
|
||||
|
||||
Performance Impact
|
||||
==================
|
||||
|
||||
The move from a bare metal OpenStack deployment to a containerized deployment
|
||||
will impact the performance of the system. These impacts will be assessed
|
||||
as the development is done and negative impacts will be mitigated.
|
||||
|
||||
Other deployer impact
|
||||
=====================
|
||||
|
||||
In order to install the StarlingX system, external network access will be
|
||||
required over the OAM interface on the controller hosts. This is necessary
|
||||
to download the required docker images, which will not be included in the
|
||||
StarlingX iso. This is both due to size considerations (the images required by
|
||||
he OpenStack application will total several GB in size) and to decouple the
|
||||
StarlingX software release from OpenStack docker image releases.
|
||||
|
||||
Patching of a StarlingX system will be different as the existing RPM based
|
||||
patching mechanism will not work for software running in containers (i.e. all
|
||||
the OpenStack components). The new patching mechanism for containers is TBD.
|
||||
|
||||
Developer impact
|
||||
================
|
||||
|
||||
Developers working on StarlingX will now need to build docker images in order
|
||||
to test changes to OpenStack components (e.g. keystone, nova, neutron) that
|
||||
were previously running on bare metal. They will also need to generate the
|
||||
OpenStack application tarfile, which includes manifests and Helm charts.
|
||||
|
||||
Upgrade impact
|
||||
==============
|
||||
|
||||
None - this is the first StarlingX release so there are no previous releases
|
||||
that we need to support upgrades from.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
===========
|
||||
|
||||
Primary assignee:
|
||||
|
||||
* Bart Wensley (bartwensley)
|
||||
|
||||
Other contributors:
|
||||
|
||||
* Al Bailey (albailey)
|
||||
* Chris Friesen (cbf123)
|
||||
* Don Penney (dpenney)
|
||||
* Jerry Sun (jerry-sun-u)
|
||||
* Kevin Smith (kevin.smith.wrs)
|
||||
* Lachlan Plant (lachlan.plant)
|
||||
* Robert Church (rchurch)
|
||||
* Shoaib Nasir (snasir)
|
||||
* Tee Ngo (teewrs)
|
||||
|
||||
Repos Impacted
|
||||
==============
|
||||
|
||||
* stx-config
|
||||
* stx-integ
|
||||
* stx-nfv
|
||||
|
||||
Work Items
|
||||
==========
|
||||
|
||||
* Sysinv:
|
||||
|
||||
* Update VIM puppet plugin to disable all OpenStack plugins in the VIM when
|
||||
the OpenStack application is NOT installed and to enable them when the
|
||||
OpenStack application is installed.
|
||||
* Support new keystone configuration (e.g. auth URL, username, password) for
|
||||
containerized OpenStack services.
|
||||
* Use the pod based keystone when accessing OpenStack services (if it is
|
||||
configured).
|
||||
* Update sysinv/puppet to supply kubernetes configuration to sysinv/VIM when
|
||||
OpenStack application has been installed.
|
||||
* Update sysinv/puppet to generate platform openrc file in
|
||||
/etc/platform/openrc.
|
||||
* Detect when OpenStack application installation is complete and:
|
||||
|
||||
* Reconfigure sysinv with pod based keystone configuration.
|
||||
* Reconfigure VIM with pod based keystone configuration.
|
||||
|
||||
* Perform different semantic checks for worker nodes with OpenStack
|
||||
installed vs. worker nodes without OpenStack.
|
||||
* Add semantic checks to prevent label and override modifications for
|
||||
unlocked hosts.
|
||||
* Send notifications to VIM whenever labels are modified.
|
||||
* Avoid modifications to host aggregates for pure kubernetes worker nodes.
|
||||
|
||||
* VIM:
|
||||
|
||||
* Support new keystone configuration (e.g. auth URL, username, password) for
|
||||
containerized OpenStack services.
|
||||
* Use the pod based keystone when accessing OpenStack services (if it is
|
||||
configured).
|
||||
* Disable all interactions with nova, neutron and guest services for pure
|
||||
kubernetes worker nodes (based on absence of openstack-compute-node label).
|
||||
* host-add:
|
||||
|
||||
* When sysinv notifies the VIM that a host has been added, the VIM will
|
||||
no longer create the nova/neutron/guest services, as the host will
|
||||
start out as a pure kubernetes worker node.
|
||||
|
||||
* label-add:
|
||||
|
||||
* When openstack-compute-node label is added to compute, create the
|
||||
nova/neutron/guest services (previously done on host-add).
|
||||
|
||||
* host-delete:
|
||||
|
||||
* Only delete OpenStack services if openstack-compute-node label applied
|
||||
to host.
|
||||
|
||||
* Remove --kubernetes option from config_controller, along with the
|
||||
now-obsolete bare metal OpenStack related code (e.g. python code, puppet,
|
||||
service scripts, OCF scripts, SM config, pmon config).
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
This requires new functionality being developed under the following stories:
|
||||
|
||||
* Kubernetes Platform Support:
|
||||
https://storyboard.openstack.org/#!/story/2002843
|
||||
* CEPH persistent storage backend for Kubernetes:
|
||||
https://storyboard.openstack.org/#!/story/2002844
|
||||
* Local Docker Registry:
|
||||
https://storyboard.openstack.org/#!/story/2002840
|
||||
* Docker Image Generation:
|
||||
https://storyboard.openstack.org/#!/story/2003907
|
||||
* Infrastructure HELM Chart Override Generation:
|
||||
https://storyboard.openstack.org/#!/story/2003909
|
||||
* Create HELM chart for nova-api-proxy:
|
||||
https://storyboard.openstack.org/#!/story/2004007
|
||||
* Create HELM chart for Fault project:
|
||||
https://storyboard.openstack.org/#!/story/2004008
|
||||
* Armada Integration:
|
||||
https://storyboard.openstack.org/#!/story/2003908
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
This story affects the configuration and deployment of all OpenStack services
|
||||
on StarlingX. In addition to the usual unit testing in the impacted code
|
||||
areas, this will require a full system regression of all StarlingX
|
||||
functionality. It will also require extensive performance testing in order
|
||||
to identify and address any performance impacts.
|
||||
|
||||
In addition, this story changes the way a StarlingX system is installed and
|
||||
configured, which will require changes in existing automated installation and
|
||||
testing tools.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
This story affects the StarlingX installation and configuration documentation.
|
||||
Specific details of the documentation changes will be addressed once the
|
||||
implementation is complete.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - 2019.03
|
||||
- Introduced
|
||||
Loading…
Reference in New Issue
Block a user