Deploying with Composable Services

Deploying with Composable Services

TripleO offers the option of deploying with a user-defined list of services per role (where “role” means group of nodes, e.g “Controller”, and “service” refers to the individual services or configurations e.g “Nova API”).

Deploying with custom service lists

Each role defines a default list of services, which can be viewed in the roles_data.yaml file (see /usr/share/openstack-tripleo-heat-templates, or the tripleo-heat-templates git repository.)

The data in roles_data.yaml is used to set the defaults for per-role parameters e.g CustomControllerServices. These defaults can be overridden via environment files, e.g:

cat > keystone_only_params.yaml << EOF

    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::RabbitMQ
    - OS::TripleO::Services::HAproxy
    - OS::TripleO::Services::MySQL
  ComputeCount: 0
  OvercloudCustomControllerFlavor: customcontroller


The example above overrides the default list of services, and instead deploys Keystone and the services it requires. It also sets the ComputeCount to zero to enable a minimal “keystone only” deployment on a single node.

You can then pass the environment file on deployment as follows:

openstack overcloud deploy -e keystone_only_params.yaml

The same approach can be used for any role.


While considerable flexibilty is available regarding service placement with these interfaces, the flexible placement of pacemaker managed services is only available since the Ocata release.


In general moving control-plane services to the Compute role is not recommended, as the compute nodes require a different upgrade lifecycle and thus control-plane services on this role may present problems during major upgrades between releases.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.