containerize-openstack.rst

Containerize OpenStack

When upgrading or downgrading OpenStack, it is possible to use package based management or image-based management. Containerizing OpenStack is meant to optimize image-based management of OpenStack. Containerizing OpenStack solves a manageability and availability problem with the current state of the art deployment systems in OpenStack.

Problem description

Current state of the art deployment systems use either image based or package based upgrade.

Image based upgrades are utilized by TripleO. When TripleO updates a system, it creates an image of the entire disk and deploys that rather than just the parts that compose the OpenStack deployment. This results in significant loss of availability. Further running VMs are shut down in the imaging process. However, image based systems offer atomicity, because all related software for a service is updated in one atomic action by reimaging the system.

Other systems use package based upgrade. Package based upgrades suffer from a non-atomic nature. An update may update 1 or more RPM packages. The update process could fail for any number of reasons, and there is no way to back out the existing changes. Typically in an OpenStack deployment it is desirable to update a service that does one thing including it's dependencies as an atomic unit. Package based upgrades do not offer atomicity.

To solve this problem, containers can be used to provide an image-based update approach which offers atomic upgrade of a running system with minimal interruption in service. A rough prototype of compute upgrade [1] shows approximately a 10 second window of unavailability during a software update. The prototype keeps virtual machines running without interruption.

Use cases

1. Upgrade or rollback OpenStack deployments atomically. End-user wants to change the running software versions in her system to deploy a new upstream release without interrupting service for significant periods.
2. Upgrade OpenStack based by component. End-user wants to upgrade her system in fine-grained chunks to limit damage from a failed upgrade.
3. Rollback OpenStack based by component. End-user experienced a failed upgrade and wishes to rollback to the last known good working version.

Proposed change

An OpenStack deployment based on containers are represented in a tree structure with each node representing a container set, and each leaf representing a container.

The full properties of a container set:

• A container set is composed of one or more container subsets or one or more individual containers
• A container set provides a single logical service
• A container set is managed as a unit during startup, shutdown, and version
• Each container set is launched together as one unit
• A container set with subsets is launched as one unit including all subsets
• A container set is not atomically managed
• A container set provides appropriate hooks for high availability monitoring

The full properties of a container:

• A container is atomically upgraded or rolled back
• A container includes a monotonically increasing generation number to identify the container's age in comparison with other containers
• A container has a single responsibility
• A container may be super-privileged when it needs significant access to the host including:
  • the network namespace of the host
  • The UUID namespace of the host
  • The IPC namespace of the host
  • Filesystem sharing of the host for persistent storage
• A container may lack any privileges when it does not require significant access to the host.
• A container should include a check function for evaluating its own health.
• A container will include proper PID 1 handling for reaping exited child processes.

The top level container sets are composed of:

• database control
• messaging control
• high availability control
• OpenStack interface
• OpenStack control
• OpenStack compute operation
• OpenStack network operation
• OpenStack storage operation