Introduction

The initial scope of this tutorial is to create a brief walkthrough with some guidelines and naming conventions for future modules and features aligned with the composable services architecture. Regarding the example described in this tutorial, which leads to align an _existing_ ‘non-composable’ service implementation with the composable roles approach, it is important to notice that a similar approach would be followed if a user needed to add an entirely new service to a tripleo deployment.

The puppet manifests used to configure services on overcloud nodes currently reside in the tripleo-heat-templates repository, in the folder puppet/manifests. In order to properly organize and structure the code, all manifests will be re-defined in the puppet-tripleo repository, and adapted to the composable services architecture.

The use case for this example uses NTP as a service installed by default among the OpenStack deployment. So the profile needs to be added to all the roles in roles_data.yaml.

Which means that NTP will be installed everywhere in the overcloud, so the tutorial will describe the process of refactoring the code from those files in order move it to the puppet-tripleo repository.

This tutorial is divided into several steps, according to different changes that need to be added to the structure of tripleo-heat-templates and puppet-tripleo.

Relevant repositories in this guide

  • tripleo-heat-templates: All the tripleo-heat-templates (aka THT) logic.

  • puppet-tripleo: TripleO puppet manifests used to deploy the overcloud services.

  • tripleo-puppet-elements: References puppet modules used by TripleO to deploy the overcloud services. (Not used in this tutorial)

Gerrit patches used in this example

The gerrit patches used to describe this walkthrough are:

Change prerequisites

The controller services are defined and configured via Heat resource chains. In the proposed patch (https://review.opendev.org/#/c/259568) controller services will be wired to a new Heat feature that allows it to dynamically include a set of nested stacks representing individual services via a Heat resource chain. The current example will use this interface to decompose the controller role into isolated services.