TripleO First Principles

The TripleO first principles are a set of principles that guide decision making around future direction with TripleO. The principles are used to evaluate choices around changes in direction and architecture. Every impactful decision does not necessarily have to follow all the principles, but we use them to make informed decisions about trade offs when necessary.

Problem Description

When evaluating technical direction within TripleO, a better and more consistent method is needed to weigh pros and cons of choices. Defining the principles is a step towards addressing that need.

Policy

Definitions

Framework

The functional implementation which exposes a set of standard enforcing interfaces that can be consumed by a service to describe that service’s deployment and management. The framework includes all functional pieces that implement such interfaces, such as CLI’s, API’s, or libraries.

Example: tripleoclient/tripleo-common/tripleo-ansible/tripleo-heat-templates

Service

The unit of deployment. A service will implement the necessary framework interfaces in order to describe it’s deployment.

The framework does not enforce a particular service boundary, other than by prescribing best practices. For example, a given service implementation could deploy both a REST API and a database, when in reality the API and database should more likely be deployed as their own services and expressed as dependencies.

Example: Keystone, MariaDB, RabbitMQ

Third party integrations

Service implementations that are developed and maintained outside of the TripleO project. These are often implemented by vendors aiming to add support for their products within TripleO.

Example: Cinder drivers, Neutron plugins

First Principles

1. [UndercloudMigrate] No Undercloud Left Behind

   1. TripleO itself as the deployment tool can be upgraded. We do not immediately propose what the upgrade will look like or the technology stack, but we will offer an upgrade path or a migration path.

2. [OvercloudMigrate] No Overcloud Left Behind

   1. An overcloud deployed with TripleO can be upgraded to the next major version with either an in place upgrade or migration.

3. [DefinedInterfaces] TripleO will have a defined interface specification.

   1. We will document clear boundaries between internal and external (third party integrations) interfaces.

   2. We will document the supported interfaces of the framework in the same way that a code library or API would be documented.

   3. Individual services of the framework can be deployed and tested in isolation from other services. Service dependencies are expressed per service, but do not preclude using the framework to deploy a service isolated from its dependencies. Whether that is successful or not depends on how the service responds to missing dependencies, and that is a behavior of the service and not the framework.

   4. The interface will offer update and upgrade tasks as first class citizens

   5. The interface will offer validation tasks as first class citizens

4. [OSProvisioningSeparation] Separation between operating system provisioning and software configuration.

   1. Baremetal configuration, network configuration and base operating system provisioning is decoupled from the software deployment.

   2. The software deployment will have a defined set of minimal requirements which are expected to be in-place before it begins the software deployment.

      1. Specific linux distributions

      2. Specific linux distribution versions

      3. Password-less access via ssh

      4. Password-less sudo access

      5. Pre-configured network bridges

5. [PlatformAgnostic] Platform agnostic deployment tooling.

   1. TripleO is sufficiently isolated from the platform in a way that allows for use in a variety of environments (baremetal/virtual/containerized/OS version).

   2. The developer experience is such that it can easily be run in isolation on developer workstations

6. [DeploymentToolingScope] The deployment tool has a defined scope

   1. Data collection tool.

      1. Responsible for collecting host and state information and posting to a centralized repository.

      2. Handles writes to central repository (e.g. read information from repository, do aggregation, post to central repository)

   2. A configuration tool to configure software and services as part of the deployment

      1. Manages Software Configuration

         1. Files

         2. Directories

         3. Service (containerized or non-containerized) state

         4. Software packages

      2. Executes commands related to “configuration” of a service Example: Configure OpenStack AZ’s, Neutron Networks.

      3. Isolated executions that are invoked independently by the orchestration tool

      4. Single execution state management

         1. Input is configuration data/tasks/etc

         2. A single execution produces the desired state or reports failure.

         3. Idempotent

      5. Read-only communication with centralized data repository for configuration data

   3. The deployment process depends on an orchestration tool to handle various task executions.

      1. Task graph manager

      2. Task transport and execution tracker

      3. Aware of hosts and work to be executed on the hosts

      4. Ephemeral deployment tooling

      5. Efficient execution

      6. Scale and reliability/durability are first class citizens

7. [CI/CDTooling] TripleO functionality should be considered within the context of being directly invoked as part of a CI/CD pipeline.

8. [DebuggableFramework] Diagnosis of deployment/configuration failures within the framework should be quick and simple. Interfaces should be provided to enable debuggability of service failures.

9. [BaseOSBootstrap] TripleO can start from a base OS and go to full cloud

   1. It should be able to start at any point after base OS, but should be able to handle the initial OS bootstrap

10. [PerServiceManagement] TripleO can manage individual services in isolation, and express and rely on dependencies and ordering between services.

11. [Predictable/Reproducible/Idempotent] The deployment is predictable

    1. The operator can determine what changes will occur before actually applying those changes.

    2. The deployment is reproducible in that the operator can re-run the deployment with the same set of inputs and achieve the same results across different environments.

    3. The deployment is idempotent in that the operator can re-run the deployment with the same set of inputs and the deployment will not change other than when it was first deployed.

    4. In the case where a service needs to restart a process, the framework will have an interface that the service can use to notify of the needed restart. In this way, the restarts are predictable.

    5. The interface for service restarts will allow for a service to describe how it should be restarted in terms of dependencies on other services, simultaneous restarts, or sequential restarts.

Non-principles

1. [ContainerImageManagement] The framework does not manage container images. Other than using a given container image to start a container, the framework does not encompass common container image management to include:

   1. Building container images

   2. Patching container images

   3. Serving or mirroring container images

   4. Caching container images

   Specific tools for container image and runtime management and that need to leverage the framework during deployment are expected to be implemented as services.

2. [SupportingTooling] Tools and software executed by the framework to deploy services or tools required prior to service deployment by the framework are not considered part of the framework itself.

   Examples: podman, TCIB, image-serve, nova-less/metalsmith

Alternatives & History

Many, if not all, the principles are already well agreed upon and understood as core to TripleO. Writing them down as policy makes them more discoverable and official.

Historically, there have been instances when decisions have been guided by desired technical implementation or outcomes. Recording the principles does not necessarily mean those decisions would stop, but it does allow for a more reasonable way to think about the trade offs.

We do not need to adopt any principles, or record them. However, there is no harm in doing so.

Implementation

Author(s)

Primary author:

James Slagle <jslagle@redhat.com>

Other contributors:

<launchpad-id or None>

Milestones

None.

Work Items

None.

References

None.

Revision History

Revisions

Release Name	Description
v0.0.1	Introduced

Note

This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode