WIXLIB

TripleO DocumentationRelease 0.0.1.dev1515OpenStack FoundationJun 01, 2021

CONTENTS1 Contributor Guide1.1 TripleO Contributor Guide . . . . . . . . . . . . . . . .1.1.1Information for New Developers . . . . . . . .1.1.2How to Contribute . . . . . . . . . . . . . . .1.1.3Core maintainers . . . . . . . . . . . . . . . .1.1.4Squads . . . . . . . . . . . . . . . . . . . . . .1.2 Developer Documentation . . . . . . . . . . . . . . . .1.2.1Composable services tutorial . . . . . . . . . .1.2.2Release Management . . . . . . . . . . . . . .1.2.3Primer python-tripleoclient and tripleo-common1.2.4Upgrades Development . . . . . . . . . . . . .222457773840422 TripleO Architecture2.1 TripleO Architecture . . . . . . . . . . .2.1.1Architecture Overview . . . . .2.1.2Benefits . . . . . . . . . . . . .2.1.3Deployment Workflow Overview2.1.4Deployment Workflow Detail . .2.1.5High Availability (HA) . . . . .2.1.6Managing the Deployment . . .60606062626367673 TripleO Components3.1 TripleO Components . . . . . . . . .3.1.1Shared Libraries . . . . . . .3.1.2Installer . . . . . . . . . . .3.1.3Node Management . . . . .3.1.4Deployment & Orchestration3.1.5User Interfaces . . . . . . .3.1.6tripleo-validations . . . . . .3.1.7Deprecated . . . . . . . . .686868707071737475.7676767881858691.4 Tripleo CI Guide4.1 TripleO CI Guide . . . . . . . . . . . . . . . . . . . . . . . . . .4.1.1TripleO CI jobs primer . . . . . . . . . . . . . . . . . .4.1.2Reproduce CI jobs for debugging and development . . .4.1.3How to add a TripleO job to your projects check pipeline4.1.4Standalone Scenario jobs . . . . . . . . . . . . . . . . .4.1.5Baremetal jobs . . . . . . . . . . . . . . . . . . . . . .4.1.6How the TripleO-RDO Pipelines Promotions Work . . .i

4.1.74.1.84.1.94.1.104.1.114.1.124.1.13TripleO CI Promotions . . . . . . . . . . . .emit-releases-file and releases.sh . . . . . . .TripleO CI ruck rover primer . . . . . . . . .Chasing CI promotions . . . . . . . . . . . .Gating github projects using TripleO CI jobsContent Provider Jobs . . . . . . . . . . . . .TripleO Dependency Pipeline . . . . . . . . .5 Install Guide5.1 TripleO Install Guide . . . . . . . . . . . . . . . .5.1.1TripleO Introduction . . . . . . . . . . .5.1.2Deploy Guide . . . . . . . . . . . . . . .5.1.3(DEPRECATED) Basic Deployment (UI)5.1.4Feature Configuration . . . . . . . . . . .5.1.5Custom Configurations . . . . . . . . . .939799103107109112.1151151151151161211296 Upgrades/Updates/FFWD-Upgrade1316.1 Upgrade, Update, FFWD Upgrade Guide . . . . . . . . . . . . . . . . . . . . . . . . . 1317 Documentation Conventions132ii

TripleO Documentation, Release 0.0.1.dev1515TripleO is a project aimed at installing, upgrading and operating OpenStack clouds using OpenStacksown cloud facilities as the foundation - building on Nova, Ironic, Neutron and Heat to automate cloudmanagement at datacenter scaleCONTENTS1

CHAPTERONECONTRIBUTOR GUIDE1.1 TripleO Contributor Guide1.1.1 Information for New DevelopersThe intention of this document is to give new developers some information regarding how to get startedwith TripleO as well as some best practices that the TripleO community has settled on.In general TripleO is a very complex chunk of software. It uses numerous technologies to implementan OpenStack installer. The premise of TripleO was to use the OpenStack platform itself as the installerand API for user interfaces. As such the first step to installing TripleO is to create what is called anundercloud. We use almost similar architecture for both undercloud and overcloud that leverages sameset of Heat templates found in tripleo-heat-templates repository, with a few minor differences. Theundercloud services are deployed in containers and can be managed by the same tool chain used forovercloud.Once the undercloud is deployed, we use a combination of Ansible playbooks and a set of Heat templates, to drive the deployment of an overcloud. Ironic is used to provision hardware and boot anoperating system either on baremetal (for real deployments) or on VMs (for development). All servicesare deployed in containers on the overcloud like undercloud.Repositories that are part of TripleO tripleo-common: This is intended to be for TripleO libraries of common code. Unfortunately ithas become a bit overrun with unrelated bits. Work is ongoing to clean this up and split this intoseparate repositories. tripleo-ansible: Contains Ansible playbooks, roles, plugins, modules, filters for use with TripleOdeployments. tripleo-heat-templates: This contains all the Heat templates necessary to deploy the overcloud(and hopefully soon the undercloud as well). python-tripleoclient: The CLI for deploying TripleO. This contains some logic but remember thatwe want to call Mistral actions from here where needed so that the logic can be shared with theUI. tripleo-docs: Where these docs are kept. tripleo-image-elements: Image elements (snippets of puppet that prepare specific parts of theimage) for building the undercloud and overcloud disk images.2

TripleO Documentation, Release 0.0.1.dev1515 tripleo-puppet-elements: Puppet elements used to configure and deploy the overcloud. These usedduring installation to set up the services. puppet-tripleo: Puppet is used to configure the services in TripleO. This repository contains various puppet modules for doing this. tripleo-quickstart: Quickstart is an Ansible driven deployment for TripleO used in CI. Most developers also use this to stand up instances for development as well. tripleo-quickstart-extras: Extended functionality for tripleo-quickstart allowing for end-to-end deployment and testing. tripleo-ui: The web based graphical user interface for deploying TripleO. kolla: We use the containers built by the Kolla project for services in TripleO. Any new containersor additions to existing containers should be submitted here. diskimage-builder: Disk image builder is used to build our base images for the TripleO deployment.Definition of DoneThis is basically a check list of things that you want to think about when implementing a new feature. Ensure that the continuous integration (CI) is in place and passing, adding coverage to tests if required. See /specs/policy/adding-ci-jobs.htmlfor more information. Ensure there are unit tests where possible. Maintain backwards compatibility with our existing template interfaces from tripleo-heattemplates. New features should be reviewed by cores who have knowledge in that area of the codebase. One should consider logging and support implications. If you have new logs, would they beavailable via sosreport. Error messages are easy to understand and work their way back to the user (stack traces are notsufficient). Documentation should be updated if necessary. New features need a tripleo-docs patch. If any new dependencies are used for your feature, be sure they are properly packaged and available in RDO. You can ask on #rdo (on OFTC server) for help with this.Using TripleO Standalone for DevelopmentThe Standalone container based deployment can be used for development purposes. This reuses theexisting TripleO Heat Templates, allowing you to do the development using this framework instead of acomplete overcloud. This is very useful if you are developing Heat templates or containerized services.Please see Standalone Deployment Guide on how to set up a Standalone OpenStack node.1.1. TripleO Contributor Guide3

TripleO Documentation, Release 0.0.1.dev15151.1.2 How to ContributeTripleO source code is publicly available. You can contribute code to individual projects, documentation,report bugs and vulnerabilities, request features.Contributing CodeAs long as TripleO is a set of integrated OpenStack projects, all development is happening in OpenStackupstream.Learn how to contribute into OpenStacks upstream.See TripleO Components to find out how to contribute into individual projects.Contacting the Core TeamPlease refer to the TripleO Core Team contacts.For upgrade specific contacts, refer to TripleO Upgrade Core contactsFor TripleO Ansible specific contacts, refer to TripleO Ansible Core contactsFor Shared TripleO CI role contacts, refer to TripleO Shared CI Core contactsContributing to this DocumentationTripleO User Documentation lives on git.opendev.org and is mirrored on GitHub under the OpenStackorganization.Learn how to contribute into TripleO Docs.Reporting BugsOpenStack Upstream: If you find bugs or vulnerabilities which affect upstream projects, please followOpenStacks process of filing bugs. Learn how to report bugs in OpenStack. If you want to file a bug against upstream project, you can find useful links in our list of TripleOComponents.TripleO If the bug impacts the TripleO project as a whole, you can file a bug in Launchpad:1. Go to https://launchpad.net/tripleo2. Fill in needed information (If you filed also upstream bug, please provide its URL in advancedfields)3. Submit bug1.1. TripleO Contributor Guide4

TripleO Documentation, Release 0.0.1.dev1515Requesting FeaturesOpenStack Upstream: Since we are developing projects in OpenStack community, all the features arebeing requested upstream via Blueprints. Learn how to create Blueprints in OpenStack. If you want to file a bug against upstream project, you can find useful links in our list of TripleOComponents.1.1.3 Core maintainersThe intention of this document is to give developers some information regarding what is expected fromcore maintainers and hopefully provide some guidance to those aiming for this role.TeamsThe TripleO Core team is responsible for reviewing all changes proposed to repositories that are underthe governance of TripleO.The TripleO Upgrade core reviewers maintain the tripleo upgrade project.The TripleO Validation team maintains the Validation Framework in TripleO.The TripleO CI team maintains the TripleO CI related projects (tripleo-ci, tripleo-quickstart, tripleoquickstart-extras, etc).We also have contributors with a specific area of expertise who have been granted core reviews on theirarea. Example: a Ceph integration expert would have core review on the Ceph related patches in TripleO.Because Gerrit doesnt allow such granularity, we trust people to understand which patches they can usetheir core reviewer status or not. If one is granted core review access on an area, there is an expectationthat itll only be used in this specific area. The grant is usually done for all the TripleO repositories butwe expect SME cores to use /- 2 for their area of expertise otherwise the regular /- 1.Note: Everyone is warmly encouraged to review incoming patches in TripleO, even if youre not (yet)a member of these teams. Participating in the review process will be a major task on the road to join thecore maintainer teams.Adding new membersEach team mentioned above should be aware of who is active in their respective project(s).In order to add someone in one of these groups, it has to be discussed between other cores and theTripleO PTL.It is a good practice to reach out to the nominee before proposing the candidate, to make sure about theirwillingness to accept this position and its responsibilities.In real life, it usually happens by informal discussions, but the official proposals have to be sent withan email to the openstack-discuss mailing list. It is strongly recommended to have this initial informalagreement before going public, in case there are some disagreements which could cause unpleasantdiscussions which could harm the nominee.1.1. TripleO Contributor Guide5