Welcome to TripleO documentation

TripleO is a project aimed at installing, upgrading and operating OpenStack clouds using OpenStack’s own cloud facilities as the foundation - building on Nova, Ironic, Neutron and Heat to automate cloud management at datacenter scale

Contributor Guide

• TripleO Contributor Guide
  • Information for New Developers
    • Repositories that are part of TripleO
    • Definition of Done
    • Using TripleO Standalone for Development
  • How to Contribute
    • Contributing Code
    • Contacting the Core Team
    • Contributing to this Documentation
    • Reporting Bugs
    • Requesting Features
  • Core maintainers
    • Teams
    • Adding new members
    • Removing members
    • Core membership expectations
    • Final note
  • Squads
• Developer Documentation
  • Composable services tutorial
    • Introduction
    • Updating tripleo-heat-templates
    • Updating puppet-tripleo
    • THT design patterns
    • TLS support for services
    • Summary
    • Service template sections description
  • Release Management
    • Releases Overview
    • Releases for RDO
  • Primer python-tripleoclient and tripleo-common
    • TripleO commands: where
    • TripleO commands: how
  • Upgrades Development
    • Overcloud Major Upgrade Workflow and CLI
    • Minor version update
    • TripleO Fast Forward Upgrade (FFU) N -> N+3
    • Major upgrades & Minor updates CI coverage

TripleO Architecture

• TripleO Architecture
  • Architecture Overview
    • TripleO
    • SpinalStack’s Inspiration
  • Benefits
  • Deployment Workflow Overview
  • Deployment Workflow Detail
    • Environment Preparation
    • Undercloud Data Preparation
    • Deployment Planning
    • Deployment
    • Per-node Setup
  • High Availability (HA)
  • Managing the Deployment
    • Monitoring the Overcloud
    • Scaling-out the Overcloud

TripleO Components

• TripleO Components
  • Shared Libraries
  • Installer
  • Node Management
  • Deployment & Orchestration
  • User Interfaces
  • tripleo-validations
  • Deprecated

Tripleo CI Guide

• TripleO CI Guide
  • TripleO CI jobs primer
    • Where do tripleo-ci jobs live
    • Zuul queues - gate vs check
    • Where do tripleo promotion jobs live
    • Contacting CI team
  • Reproduce CI jobs for debugging and development
    • RDO’s zuul:
    • Local zuul:
    • zuul-runner:
    • Other Options:
    • Summary:
  • How to add a TripleO job to your projects check pipeline
    • Project Config Example
    • How to pick which job to execute for any given OpenStack project
    • Adding a new non-voting check job
    • Enabling voting jobs
    • Troubleshooting a failed job
    • Enabling tempest tests notification
    • featureset override
  • Standalone Scenario jobs
    • Where
    • How
  • Baremetal jobs
    • Where
    • How
    • Parenting from upstream and RDO repos
    • Hardware Settings
  • How the TripleO-RDO Pipelines’ Promotions Work
    • What is DLRN?
    • DLRN Artifacts - Hashes and Repos
    • Promoting through the Stages - DLRN API
  • TripleO CI Promotions
    • TripleO vs non-tripleo repos
    • RDO DLRN & Promotion Criteria
    • The TripleO Promotion Pipelines
    • The Component Promotion Pipeline
    • The Integration Promotion Pipeline
  • emit-releases-file and releases.sh
    • Where is releases.sh used
  • TripleO CI ruck|rover primer
    • Ruck
    • Rover
    • Tools
  • Chasing CI promotions
    • Successful promotion
    • TripleO periodic jobs
    • Promotion Server and Criteria
    • Hack the promotion with testproject
  • Gating github projects using TripleO CI jobs
    • Jobs running against ceph-ansible
    • Jobs running against podman
    • Report bugs when Jobs start failing
    • check-rdo vs check-github
    • Using Depends-On on ceph-ansible/podman pull requests
  • Content Provider Jobs
    • Why Do We Need Content Providers?
    • The Content Provider
    • The Content Consumers
    • Upgrade Jobs
  • TripleO Dependency Pipeline
    • Current OpenStack Dependency Pipeline jobs
    • Understanding Package Dependency Pipeline
    • Understanding CentOS Compose Pinning Dependency
    • Testing Jobs Using Compose Pinning Dependency
    • Ensuring Correct Module or Repo is Used
  • TripleO CI Zuul Jobs Parenting
    • Zuul Job Parenting
    • TripleO CI Base jobs
    • Required Project Jobs
    • Distribution Jobs
    • Zuul Job Inheritance Order
    • TripleO CI Zuul Job Repos
    • FAQs regarding TripleO CI jobs

Install Guide

• TripleO Install Guide
  • TripleO Introduction
    • TripleO Architecture
    • TripleO Components
  • Deploy Guide
  • (DEPRECATED) Basic Deployment (UI)
    • Prepare Your Environment
    • Access the UI
    • Manage Plans
    • Manage Nodes
    • Configure the Deployment
    • Assign Nodes
    • Deploy the Overcloud
    • Post-Deployment
  • Feature Configuration
    • (DEPRECATED) Deploying OpenShift
  • Custom Configurations
    • Exporting Deployment Plans

Upgrades/Updates/FFWD-Upgrade

• Upgrade, Update, FFWD Upgrade Guide
  • Upgrades Development
    • Overcloud Major Upgrade Workflow and CLI
    • Minor version update
    • TripleO Fast Forward Upgrade (FFU) N -> N+3
    • Major upgrades & Minor updates CI coverage

Documentation Conventions

Some steps in the following instructions only apply to certain environments, such as deployments to real baremetal and deployments using Red Hat Enterprise Linux (RHEL). These steps are marked as follows:

RHEL

Step that should only be run when using RHEL

RHEL Portal Registration

Step that should only be run when using RHEL Portal Registration

RHEL Satellite Registration

Step that should only be run when using RHEL Satellite Registration

CentOS

Step that should only be run when using CentOS

Baremetal

Step that should only be run when deploying to baremetal

Virtual

Step that should only be run when deploying to virtual machines

Ceph

Step that should only be run when deploying Ceph for use by the Overcloud

Stable Branch

Step that should only be run when choosing to use components from their stable branches rather than using packages/source based on current master.

Wallaby

Step that should only be run when installing from the Wallaby stable branch.

Xena

Step that should only be run when installing from the Xena stable branch.

Yoga

Step that should only be run when installing from the Yoga stable branch.

Zed

Step that should only be run when installing from the Zed stable branch.

Validations

Steps that will run the pre and post-deployment validations

Optional Feature

Step that is optional. A deployment can be done without these steps, but they may provide useful additional functionality.

Any such steps should not be run if the target environment does not match the section marking.