Chapter 6. Composable Services and Custom Roles
The Overcloud usually consists of nodes in predefined roles such as Controller nodes, Compute nodes, and different storage node types. Each of these default roles contains a set of services defined in the core Heat template collection on the director node. However, the architecture of the core Heat templates provide methods to:
- Create custom roles
- Add and remove services from each role
This allows the possibility to create different combinations of services on different roles. This chapter explores the architecture of custom roles, composable services, and methods for using them.
6.1. Supported Custom Role Architecture
Only a limited number of composable service combinations have been tested and verified. Red Hat supports the following architectures when using custom roles and composable services:
- Architecture 1 - Monolithic Controller
- All controller services are contained within one Controller role. This is the default. See Section 6.5.1, “Service Architecture: Monolithic Controller” for more details.
- Architecture 2 - Split Controller
The controller services are split into two roles:
- Controller PCMK - Core Pacemaker-managed services such as database and load balancing
- Controller Systemd - 'systemd`-managed OpenStack Platform services
See Section 6.5.2, “Service Architecture: Split Controller” for more details.
- Architecture 3 - Standalone roles
- Use Architecture 1 or Architecture 2, except split the OpenStack Platform services into custom roles. See Section 6.5.3, “Service Architecture: Standalone Roles” for more details.
6.2. Guidelines and Limitations
Note the following guidelines and limitations for the composable node architecture.
For systemd
services:
-
You can assign
systemd
managed services to supported standalone custom roles. -
You can create additional custom roles after the initial deployment and deploy them to scale existing
systemd
services.
For Pacemaker-managed services:
- You can assign Pacemaker managed services to supported standalone custom roles.
-
Pacemaker has a 16 node limit. If you assign the Pacemaker service (
OS::TripleO::Services::Pacemaker
) to 16 nodes, any subsequent nodes must use the Pacemaker Remote service (OS::TripleO::Services::PacemakerRemote
) instead. You cannot have the Pacemaker service and Pacemaker Remote service on the same role. -
Do not include the Pacemaker service (
OS::TripleO::Services::Pacemaker
) on roles that do not contain Pacemaker managed services. -
You cannot scale up or scale down a custom roles that contains
OS::TripleO::Services::Pacemaker
orOS::TripleO::Services::PacemakerRemote
services.
General Limitations:
- You cannot change custom roles and composable services during the upgrade process from Red Hat OpenStack Platform 11 to 12.
- You cannot modify the list of services for any role after deploying an Overcloud. Modifying the service lists after Overcloud deployment can cause deployment errors and leave orphaned services on nodes.
6.3. Roles
6.3.1. Examining the roles_data File
The Overcloud creation process defines its roles using a roles_data
file. The roles_data
file contains a YAML-formatted list of the roles. The following is a shortened example of the roles_data
syntax:
- name: Controller description: | Controller role that has all the controler services loaded and handles Database, Messaging and Network functions. ServicesDefault: - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CephClient ... - name: Compute description: | Basic Compute Node role ServicesDefault: - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CephClient ...
The core Heat template collection contains a default roles_data
file located at /usr/share/openstack-tripleo-heat-templates/roles_data.yaml
. The default file defines the following role types:
-
Controller
-
Compute
-
BlockStorage
-
ObjectStorage
-
CephStorage
.
The openstack overcloud deploy
command includes this file during deployment. You can override this file with a custom roles_data
file using the -r
argument. For example:
$ openstack overcloud deploy --templates -r ~/templates/roles_data-custom.yaml
6.3.2. Creating a role_data File
Although you can manually create a custom roles_data
file, you can also automatically generating the file using individual role templates. The director provides a several commands to manage role templates and automatically generate a custom roles_data
file.
To list the default role templates, use the openstack overcloud role list
command:
$ openstack overcloud role list BlockStorage CephStorage Compute ComputeHCI ComputeOvsDpdk Controller ...
To see the role’s YAML definition, use the openstack overcloud role show
command:
$ openstack overcloud role show Compute
To generate a custom roles_data
file, use the openstack overcloud roles generate
command to join multiple predefined roles into a single file. For example, the following command joins the Controller
, Compute
, and Networker
roles into a single file:
$ openstack overcloud roles generate -o ~/roles_data.yaml Controller Compute Networker
The -o
defines the name of the file to create.
This creates a custom roles_data
file. However, the previous example uses the Controller
and Networker
roles, which both contain the same networking agents. This means the networking services scale from Controller
to the Networker
role. The overcloud balance the load for networking services between the Controller
and Networker
nodes.
To make this Networker
role standalone, you can create your own custom Controller
role, as well as any other role needed. This allows you to easily generate a roles_data
file from your own custom roles.
Copy the directory from the core Heat template collection to the stack
user’s home directory:
$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
Add or modify the custom role files in this directory. Use the --roles-path
option with any of the aforementioned role sub-commands to use this directory as the source for your custom roles. For example:
$ openstack overcloud roles generate -o my_roles_data.yaml \ --roles-path ~/roles \ Controller Compute Networker
This generates a single my_roles_data.yaml
file from the individual roles in the ~/roles
directory.
The default roles collection also contains the ControllerOpenStack
role, which does not include services for Networker
, Messaging
, and Database
roles. You can use the ControllerOpenStack
combined with with the standalone Networker
, Messaging
, and Database
roles.
6.3.3. Examining Role Parameters
Each role uses the following parameters:
- name
-
(Mandatory) The name of the role, which is a plain text name with no spaces or special characters. Check that the chosen name does not cause conflicts with other resources. For example, use
Networker
as a name instead ofNetwork
. For recommendations on role names, see Section 6.5.2, “Service Architecture: Split Controller” for examples. - description
- (Optional) A plain text description for the role.
- tags
(Optional) A YAML list of tags that o define role properties. Use this parameter to define the primary role with both the
controller
andprimary
tags together:- name: Controller ... tags: - primary - controller ...
If you do not tag the primary role, the first role defined becomes the primary role. Ensure this role is the Controller role.
- networks
-
A list of networks to configure on the role. Default networks include
External
,InternalApi
,Storage
,StorageMgmt
,Tenant
, andManagement
. - CountDefault
- (Optional) Defines the default number of nodes to deploy for this role.
- HostnameFormatDefault
(Optional) Defines the default hostname format for the role. The default naming convention uses the following format:
[STACK NAME]-[ROLE NAME]-[NODE ID]
For example, the default Controller nodes are named:
overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ...
- disable_constraints
- (Optional) Defines whether to disable OpenStack Compute (nova) and OpenStack Image Storage (glance) constraints when deploying with the director. Used when deploying an overcloud with pre-provisioned nodes. For more information, see "Configuring a Basic Overcloud using Pre-Provisioned Nodes" in the Director Installation and Usage Guide.
- disable_upgrade_deployment
- (Optional) Defines whether to disable upgrades for a specific role. This provides a method to upgrade individual nodes in a role and ensure availability of services. For example, the Compute and Swift Storage roles use this parameter.
- upgrade_batch_size
- (Optional) Defines the number of tasks to execute in a batch during the upgrade. A task counts as one upgrade step per node. The default batch size is 1, which means the upgrade process executes a single upgrade step on each node one at a time. Increasing the batch size increases the number of tasks executed simultaneously on nodes
- ServicesDefault
- (Optional) Defines the default list of services to include on the node. See Section 6.4.1, “Examining Composable Service Architecture” for more information.
These parameters provide a means to create new roles and also define which services to include.
The openstack overcloud deploy
command integrates the parameters from the roles_data
file into some of the Jinja2-based templates. For example, at certain points, the overcloud.j2.yaml
Heat template iterates over the list of roles from roles_data.yaml
and creates parameters and resources specific to each respective role.
The resource definition for each role in the overcloud.j2.yaml
Heat template appears as the following snippet:
{{role.name}}: type: OS::Heat::ResourceGroup depends_on: Networks properties: count: {get_param: {{role.name}}Count} removal_policies: {get_param: {{role.name}}RemovalPolicies} resource_def: type: OS::TripleO::{{role.name}} properties: CloudDomain: {get_param: CloudDomain} ServiceNetMap: {get_attr: [ServiceNetMap, service_net_map]} EndpointMap: {get_attr: [EndpointMap, endpoint_map]} ...
This snippet shows how the Jinja2-based template incorporates the {{role.name}}
variable to define the name of each role as a OS::Heat::ResourceGroup
resource. This in turn uses each name
parameter from the roles_data
file to name each respective OS::Heat::ResourceGroup
resource.
6.3.4. Creating a New Role
In this example, the aim is to create a new Horizon
role to host the OpenStack Dashboard (horizon
) only. In this situation, you create a custom roles
directory that includes the new role information.
Create a custom copy of the default roles
directory:
$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
Create a new file called ~/roles/Horizon.yaml
and create a new Horizon
role containing base and core OpenStack Dashboard services. For example:
- name: Horizon CountDefault: 1 HostnameFormatDefault: '%stackname%-horizon-%index%' ServicesDefault: - OS::TripleO::Services::CACerts - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::Snmp - OS::TripleO::Services::Sshd - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::SensuClient - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::AuditD - OS::TripleO::Services::Collectd - OS::TripleO::Services::MySQLClient - OS::TripleO::Services::Apache - OS::TripleO::Services::Horizon
It is also a good idea to set the CountDefault
to 1
so that a default Overcloud always includes the Horizon
node.
If scaling the services in an existing overcloud, keep the existing services on the Controller
role. If creating a new overcloud and you want the OpenStack Dashboard to remain on the standalone role, remove the OpenStack Dashboard components from the Controller
role definition:
- name: Controller CountDefault: 1 ServicesDefault: ... - OS::TripleO::Services::GnocchiMetricd - OS::TripleO::Services::GnocchiStatsd - OS::TripleO::Services::HAproxy - OS::TripleO::Services::HeatApi - OS::TripleO::Services::HeatApiCfn - OS::TripleO::Services::HeatApiCloudwatch - OS::TripleO::Services::HeatEngine # - OS::TripleO::Services::Horizon # Remove this service - OS::TripleO::Services::IronicApi - OS::TripleO::Services::IronicConductor - OS::TripleO::Services::Iscsid - OS::TripleO::Services::Keepalived ...
Generate the new roles_data
file using the roles
directory as the source:
$ openstack overcloud roles generate -o roles_data-horizon.yaml \ --roles-path ~/roles \ Controller Compute Horizon
You might need to define a new flavor for this role so that you can tag specific nodes. For this example, use the following commands to create a horizon
flavor:
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 horizon $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="horizon" horizon
Tag nodes into the new flavor using the following command:
$ openstack baremetal node set --property capabilities='profile:horizon,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
Define the Horizon node count and flavor using the following environment file snippet:
parameter_defaults: OvercloudHorizonFlavor: horizon HorizonCount: 1
Include the new roles_data
file and environment file when running the openstack overcloud deploy
command. For example:
$ openstack overcloud deploy --templates -r ~/templates/roles_data-horizon.yaml -e ~/templates/node-count-flavor.yaml
When the deployment completes, this creates a three-node Overcloud consisting of one Controller node, one Compute node, and one Networker node. To view the Overcloud’s list of nodes, run the following command:
$ openstack server list
6.4. Composable Services
6.4.1. Examining Composable Service Architecture
The core Heat template collection contains a collection of composable service templates in the puppet/services
subdirectory. You can view these services with the following command:
$ ls /usr/share/openstack-tripleo-heat-templates/puppet/services
Each service template contains a description that identifies its purpose. For example, the keystone.yaml
service template contains the following description:
description: > OpenStack Identity (`keystone`) service configured with Puppet
These service templates are registered as resources specific to a Red Hat OpenStack Platform deployment. This means you can call each resource using a unique Heat resource namespace defined in the overcloud-resource-registry-puppet.j2.yaml
file. All services use the OS::TripleO::Services
namespace for their resource type. For example, the keystone.yaml
service template is registered to the OS::TripleO::Services::Keystone
resource type:
grep "OS::TripleO::Services::Keystone" /usr/share/openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.j2.yaml OS::TripleO::Services::Keystone: puppet/services/keystone.yaml
The overcloud.j2.yaml
Heat template includes a section of Jinja2-based code to define a service list for each custom role in the roles_data.yaml
file:
{{role.name}}Services: description: A list of service resources (configured in the Heat resource_registry) which represent nested stacks for each service that should get installed on the {{role.name}} role. type: comma_delimited_list default: {{role.ServicesDefault|default([])}}
For the default roles, this creates the following service list parameters: ControllerServices
, ComputeServices
, BlockStorageServices
, ObjectStorageServices
, and CephStorageServices
.
You define the default services for each custom role in the roles_data.yaml
file. For example, the default Controller role contains the following content:
- name: Controller CountDefault: 1 ServicesDefault: - OS::TripleO::Services::CACerts - OS::TripleO::Services::CephMon - OS::TripleO::Services::CephExternal - OS::TripleO::Services::CephRgw - OS::TripleO::Services::CinderApi - OS::TripleO::Services::CinderBackup - OS::TripleO::Services::CinderScheduler - OS::TripleO::Services::CinderVolume - OS::TripleO::Services::Core - OS::TripleO::Services::Kernel - OS::TripleO::Services::Keystone - OS::TripleO::Services::GlanceApi - OS::TripleO::Services::GlanceRegistry ...
These services are then defined as the default list for the ControllerServices
parameter.
You can also use an environment file to override the default list for the service parameters. For example, you can define ControllerServices
as a parameter_default
in an environment file to override the services list from the roles_data.yaml
file.
6.4.2. Adding and Removing Services from Roles
The basic method of adding or removing services involves creating a copy of the default service list for a node role and then adding or removing services. For example, you might aim to remove OpenStack Orchestration (heat
) from the Controller nodes. In this situation, create a custom copy of the default roles
directory:
$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.
Edit the ~/roles/Controller.yaml
file and modify the service list for the ServicesDefault
parameter. Scroll to the OpenStack Orchestration services and remove them:
- OS::TripleO::Services::GlanceApi - OS::TripleO::Services::GlanceRegistry - OS::TripleO::Services::HeatApi # Remove this service - OS::TripleO::Services::HeatApiCfn # Remove this service - OS::TripleO::Services::HeatApiCloudwatch # Remove this service - OS::TripleO::Services::HeatEngine # Remove this service - OS::TripleO::Services::MySQL - OS::TripleO::Services::NeutronDhcpAgent
Generate the new roles_data
file. For example:
$ openstack overcloud roles generate -o roles_data-no_heat.yaml \ --roles-path ~/roles \ Controller Compute Networker
Include this new roles_data
file when running the openstack overcloud deploy
command. For example:
$ openstack overcloud deploy --templates -r ~/templates/roles_data-no_heat.yaml
This deploys an Overcloud without OpenStack Orchestration services installed on the Controller nodes.
You can also disable services in the roles_data
file using a custom environment file. Redirect the services to disable to the OS::Heat::None
resource. For example:
resource_registry: OS::TripleO::Services::HeatApi: OS::Heat::None OS::TripleO::Services::HeatApiCfn: OS::Heat::None OS::TripleO::Services::HeatApiCloudwatch: OS::Heat::None OS::TripleO::Services::HeatEngine: OS::Heat::None
6.4.3. Enabling Disabled Services
Some services are disabled by default. These services are registered as null operations (OS::Heat::None
) in the overcloud-resource-registry-puppet.j2.yaml
file. For example, the Block Storage backup service (cinder-backup
) is disabled:
OS::TripleO::Services::CinderBackup: OS::Heat::None
To enable this service, include an environment file that links the resource to its respective Heat templates in the puppet/services
directory. Some services have predefined environment files in the environments
directory. For example, the Block Storage backup service uses the environments/cinder-backup.yaml
file, which contains the following:
resource_registry: OS::TripleO::Services::CinderBackup: ../puppet/services/pacemaker/cinder-backup.yaml ...
This overrides the default null operation resource and enables the service. Include this environment file when running the openstack overcloud deploy
command.
$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml
For another example of how to enable disabled services, see the Installation section of the OpenStack Data Processing guide. This section contains instructions on how to enable the OpenStack Data Processing service (sahara
) on the overcloud.
6.4.4. Creating a Generic Node with No Services
Red Hat OpenStack Platform provides the ability to create generic Red Hat Enterprise Linux 7 nodes without any OpenStack services configured. This is useful in situations where you need to host software outside of the core Red Hat OpenStack Platform environment. For example, OpenStack Platform provides integration with monitoring tools such as Kibana and Sensu (see Monitoring Tools Configuration Guide). While Red Hat does not provide support for the monitoring tools themselves, the director can create a generic Red Hat Enterprise Linux 7 node to host these tools.
The generic node still uses the base overcloud-full
image rather than a base Red Hat Enterprise Linux 7 image. This means the node has some Red Hat OpenStack Platform software installed but not enabled or configured.
Creating a generic node requires a new role without a ServicesDefault
list:
- name: Generic
Include the role in your custom roles_data
file (roles_data_with_generic.yaml
). Make sure to keep the existing Controller
and Compute
roles.
You can also include an environment file (generic-node-params.yaml
) to specify how many generic Red Hat Enterprise Linux 7 nodes you require and the flavor when selecting nodes to provision. For example:
parameter_defaults: OvercloudGenericFlavor: baremetal GenericCount: 1
Include both the roles file and the environment file when running the openstack overcloud deploy
command. For example:
$ openstack overcloud deploy --templates -r ~/templates/roles_data_with_generic.yaml -e ~/templates/generic-node-params.yaml
This deploys a three-node environment with one Controller node, one Compute node, and one generic Red Hat Enterprise Linux 7 node.
6.5. Architectures
6.5.1. Service Architecture: Monolithic Controller
The default architecture for composable services uses a monolithic Controller that contains the core Red Hat OpenStack Platform Services. These default services are defined in the roles file included with the director’s Heat template collection (/usr/share/openstack-tripleo-heat-templates/roles_data.yaml
).
Some services are disabled by default. See Section 6.4.3, “Enabling Disabled Services” for information on how to enable these services.
- name: Controller # the 'primary' role goes first CountDefault: 1 ServicesDefault: - OS::TripleO::Services::CACerts - OS::TripleO::Services::CephMds - OS::TripleO::Services::CephMon - OS::TripleO::Services::CephExternal - OS::TripleO::Services::CephRbdMirror - OS::TripleO::Services::CephRgw - OS::TripleO::Services::CinderApi - OS::TripleO::Services::CinderBackup - OS::TripleO::Services::CinderScheduler - OS::TripleO::Services::CinderVolume - OS::TripleO::Services::CinderBackendDellPs - OS::TripleO::Services::CinderBackendDellSc - OS::TripleO::Services::CinderBackendNetApp - OS::TripleO::Services::CinderBackendScaleIO - OS::TripleO::Services::Congress - OS::TripleO::Services::Kernel - OS::TripleO::Services::Keystone - OS::TripleO::Services::GlanceApi - OS::TripleO::Services::HeatApi - OS::TripleO::Services::HeatApiCfn - OS::TripleO::Services::HeatApiCloudwatch - OS::TripleO::Services::HeatEngine - OS::TripleO::Services::MySQL - OS::TripleO::Services::MySQLClient - OS::TripleO::Services::NeutronDhcpAgent - OS::TripleO::Services::NeutronL3Agent - OS::TripleO::Services::NeutronMetadataAgent - OS::TripleO::Services::NeutronApi - OS::TripleO::Services::NeutronCorePlugin - OS::TripleO::Services::NeutronOvsAgent - OS::TripleO::Services::RabbitMQ - OS::TripleO::Services::HAproxy - OS::TripleO::Services::Keepalived - OS::TripleO::Services::Memcached - OS::TripleO::Services::Pacemaker - OS::TripleO::Services::Redis - OS::TripleO::Services::NovaConductor - OS::TripleO::Services::MongoDb - OS::TripleO::Services::NovaApi - OS::TripleO::Services::NovaPlacement - OS::TripleO::Services::NovaMetadata - OS::TripleO::Services::NovaScheduler - OS::TripleO::Services::NovaConsoleauth - OS::TripleO::Services::NovaVncProxy - OS::TripleO::Services::Ec2Api - OS::TripleO::Services::Ntp - OS::TripleO::Services::SwiftProxy - OS::TripleO::Services::SwiftStorage - OS::TripleO::Services::SwiftRingBuilder - OS::TripleO::Services::Snmp - OS::TripleO::Services::Sshd - OS::TripleO::Services::Timezone - OS::TripleO::Services::CeilometerApi - OS::TripleO::Services::CeilometerCollector - OS::TripleO::Services::CeilometerExpirer - OS::TripleO::Services::CeilometerAgentCentral - OS::TripleO::Services::CeilometerAgentNotification - OS::TripleO::Services::Horizon - OS::TripleO::Services::GnocchiApi - OS::TripleO::Services::GnocchiMetricd - OS::TripleO::Services::GnocchiStatsd - OS::TripleO::Services::ManilaApi - OS::TripleO::Services::ManilaScheduler - OS::TripleO::Services::ManilaBackendGeneric - OS::TripleO::Services::ManilaBackendNetapp - OS::TripleO::Services::ManilaBackendCephFs - OS::TripleO::Services::ManilaShare - OS::TripleO::Services::AodhApi - OS::TripleO::Services::AodhEvaluator - OS::TripleO::Services::AodhNotifier - OS::TripleO::Services::AodhListener - OS::TripleO::Services::SaharaApi - OS::TripleO::Services::SaharaEngine - OS::TripleO::Services::IronicApi - OS::TripleO::Services::IronicConductor - OS::TripleO::Services::NovaIronic - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::OpenDaylightApi - OS::TripleO::Services::OpenDaylightOvs - OS::TripleO::Services::SensuClient - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Collectd - OS::TripleO::Services::BarbicanApi - OS::TripleO::Services::PankoApi - OS::TripleO::Services::Tacker - OS::TripleO::Services::Zaqar - OS::TripleO::Services::OVNDBs - OS::TripleO::Services::NeutronML2FujitsuCfab - OS::TripleO::Services::NeutronML2FujitsuFossw - OS::TripleO::Services::CinderHPELeftHandISCSI - OS::TripleO::Services::Etcd - OS::TripleO::Services::AuditD - OS::TripleO::Services::OctaviaApi - OS::TripleO::Services::OctaviaHealthManager - OS::TripleO::Services::OctaviaHousekeeping - OS::TripleO::Services::OctaviaWorker
6.5.2. Service Architecture: Split Controller
You can split the services on the Controller nodes into two separate roles:
- Controller PCMK - Contains only the core services that Pacemaker manages including database and load balancing
- Controller systemd - Contains all OpenStack services
The remaining default roles (Compute, Ceph Storage, Object Storage, Block Storage) remain unaffected.
Use the following tables as a guide to creating a split controller architecture.
Some services are disabled by default. See Section 6.4.3, “Enabling Disabled Services” for information on how to enable these services.
Controller PCMK
The following services are the minimum services required for the Controller PCMK role.
- name: Controller ServicesDefault: - OS::TripleO::Services::CACerts - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::Snmp - OS::TripleO::Services::Sshd - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::SensuClient - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::AuditD - OS::TripleO::Services::Collectd - OS::TripleO::Services::MySQLClient - OS::TripleO::Services::CephClient - OS::TripleO::Services::CephExternal - OS::TripleO::Services::CinderBackup - OS::TripleO::Services::CinderVolume - OS::TripleO::Services::HAproxy - OS::TripleO::Services::Keepalived - OS::TripleO::Services::ManilaBackendGeneric - OS::TripleO::Services::ManilaBackendNetapp - OS::TripleO::Services::ManilaBackendCephFs - OS::TripleO::Services::ManilaShare - OS::TripleO::Services::Memcached - OS::TripleO::Services::MySQL - OS::TripleO::Services::Pacemaker - OS::TripleO::Services::RabbitMQ - OS::TripleO::Services::Redis
Controller systemd
The following table represents the services available on the Controller systemd role:
- name: ControllerSystemd ServicesDefault: - OS::TripleO::Services::CACerts - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::Snmp - OS::TripleO::Services::Sshd - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::SensuClient - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::AuditD - OS::TripleO::Services::Collectd - OS::TripleO::Services::MySQLClient - OS::TripleO::Services::Apache - OS::TripleO::Services::AodhApi - OS::TripleO::Services::AodhEvaluator - OS::TripleO::Services::AodhListener - OS::TripleO::Services::AodhNotifier - OS::TripleO::Services::CeilometerAgentCentral - OS::TripleO::Services::CeilometerAgentNotification - OS::TripleO::Services::CeilometerApi - OS::TripleO::Services::CeilometerCollector - OS::TripleO::Services::CeilometerExpirer - OS::TripleO::Services::CephClient - OS::TripleO::Services::CephExternal - OS::TripleO::Services::CephMon - OS::TripleO::Services::CephRgw - OS::TripleO::Services::CinderApi - OS::TripleO::Services::CinderScheduler - OS::TripleO::Services::GlanceApi - OS::TripleO::Services::GnocchiApi - OS::TripleO::Services::GnocchiMetricd - OS::TripleO::Services::GnocchiStatsd - OS::TripleO::Services::HeatApi - OS::TripleO::Services::HeatApiCfn - OS::TripleO::Services::HeatApiCloudwatch - OS::TripleO::Services::HeatEngine - OS::TripleO::Services::Horizon - OS::TripleO::Services::IronicApi - OS::TripleO::Services::IronicConductor - OS::TripleO::Services::Keystone - OS::TripleO::Services::ManilaApi - OS::TripleO::Services::ManilaScheduler - OS::TripleO::Services::MongoDb - OS::TripleO::Services::MySQLClient - OS::TripleO::Services::NeutronApi - OS::TripleO::Services::NeutronCorePlugin - OS::TripleO::Services::NeutronCorePluginML2OVN - OS::TripleO::Services::NeutronCorePluginMidonet - OS::TripleO::Services::NeutronCorePluginNuage - OS::TripleO::Services::NeutronCorePluginOpencontrail - OS::TripleO::Services::NeutronCorePluginPlumgrid - OS::TripleO::Services::NeutronDhcpAgent - OS::TripleO::Services::NeutronL3Agent - OS::TripleO::Services::NeutronMetadataAgent - OS::TripleO::Services::NeutronOvsAgent - OS::TripleO::Services::NovaApi - OS::TripleO::Services::NovaConductor - OS::TripleO::Services::NovaConsoleauth - OS::TripleO::Services::NovaIronic - OS::TripleO::Services::NovaPlacement - OS::TripleO::Services::NovaScheduler - OS::TripleO::Services::NovaVncProxy - OS::TripleO::Services::OpenDaylightApi - OS::TripleO::Services::OpenDaylightOvs - OS::TripleO::Services::PankoApi - OS::TripleO::Services::SaharaApi - OS::TripleO::Services::SaharaEngine - OS::TripleO::Services::SwiftProxy - OS::TripleO::Services::SwiftRingBuilder
6.5.3. Service Architecture: Standalone Roles
The following tables list the supported custom role collection you can create and scale with the composable service architecture in Red Hat OpenStack Platform. Group these collections together as individual roles and use them to isolate and split services in combination with the previous architectures:
Some services are disabled by default. See Section 6.4.3, “Enabling Disabled Services” for information on how to enable these services.
Note that all roles use a set of common services, which include:
-
OS::TripleO::Services::AuditD
-
OS::TripleO::Services::CACerts
-
OS::TripleO::Services::CertmongerUser
-
OS::TripleO::Services::Collectd
-
OS::TripleO::Services::ContainersLogrotateCrond
-
OS::TripleO::Services::Docker
-
OS::TripleO::Services::FluentdClient
-
OS::TripleO::Services::Kernel
-
OS::TripleO::Services::Ntp
-
OS::TripleO::Services::SensuClient
-
OS::TripleO::Services::Snmp
-
OS::TripleO::Services::Timezone
-
OS::TripleO::Services::TripleoFirewall
-
OS::TripleO::Services::TripleoPackages
-
OS::TripleO::Services::Tuned
Once you have chosen the roles to include in your overcloud, remove the associated services (except for the common services) from the main Controller roles. For example, if creating a standalone Keystone role, remove the OS::TripleO::Services::Apache
and OS::TripleO::Services::Keystone
services from the Controller nodes. The only exceptions are the services with limited custom role support (see Table 6.1, “Custom Roles Support”).
Click on a role in the following table to view the services associated with it.
Role | Support Status |
---|---|
Supported | |
Supported | |
Limited. If spliting, this service needs to be part of a Controller systemd role. | |
Supported | |
Supported | |
Supported | |
Supported | |
Supported | |
Supported | |
Supported | |
Supported | |
Supported | |
Limited. If spliting, this service needs to be part of a Controller systemd role. | |
Supported | |
Supported | |
Supported | |
Supported | |
Supported | |
Technical Preview | |
Supported | |
Limited. If spliting, this service needs to be part of a Controller systemd role. | |
Supported | |
Supported | |
Supported |
Ceph Storage Monitor
The following services configure Ceph Storage Monitor.
- name: CephMon ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::CephMon
Ceph Storage OSD
The following services configure Ceph Storage OSDs.
- name: CephStorage ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::CephOSD
Ceph Storage RadosGW
The following services configure Ceph Storage RadosGW. If separating these services, they need to be part of a Controller systemd role.
# Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::CephRgw
Cinder API
The following services configure the OpenStack Block Storage API.
- name: CinderApi ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::CinderApi - OS::TripleO::Services::CinderScheduler
Controller PCMK
The following services are the minimum services required for the Controller PCMK as a standalone role.
- name: Controller ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::CephClient - OS::TripleO::Services::CephExternal - OS::TripleO::Services::CinderBackup - OS::TripleO::Services::CinderVolume - OS::TripleO::Services::Keepalived - OS::TripleO::Services::ManilaBackendGeneric - OS::TripleO::Services::ManilaBackendNetapp - OS::TripleO::Services::ManilaBackendCephFs - OS::TripleO::Services::ManilaShare - OS::TripleO::Services::Memcached - OS::TripleO::Services::Pacemaker
This is the same as the Controller PCMK role in the Split Controller Architecture. The difference is you can split the following highly available services to standalone roles:
If not, creating standalone roles for these services, merge the services from these roles into the Controller PCMK standalone role.
Database
The following services configure the main database. The database is MariaDB managed as a Galera cluster using Pacemaker.
- name: Database ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::Pacemaker - OS::TripleO::Services::MySQL
Glance
The following services configure the OpenStack Image service.
- name: Glance ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::CephClient - OS::TripleO::Services::CephExternal - OS::TripleO::Services::GlanceApi
Heat
The following services configure the OpenStack Orchestration service.
- name: Heat ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::HeatApi - OS::TripleO::Services::HeatApiCfn - OS::TripleO::Services::HeatApiCloudwatch - OS::TripleO::Services::HeatEngine
Horizon
The following services configure the OpenStack Dashboard.
- name: Horizon ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::Apache - OS::TripleO::Services::Horizon
Ironic
The following services configure the OpenStack Bare Metal Provisioning service.
- name: Ironic ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::IronicApi - OS::TripleO::Services::IronicConductor - OS::TripleO::Services::IronicPxe
Note the following:
- Requires access to the Storage network.
-
The
OS::TripleO::Services::IronicApi
service can exist on either theIronic
role or theController
role depending on your requirements. -
Requires the
OS::TripleO::Services::NovaIronic
service on theController
role.
Keystone
The following services configure the OpenStack Identity service. When performing minor updates, make sure to update this role before updating other services.
- name: Keystone ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::Apache - OS::TripleO::Services::Keystone
Load Balancer
The following services configure the overcloud’s load balancer. The load balancer is HAProxy managed with Pacemaker.
- name: LoadBalancer ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::Pacemaker - OS::TripleO::Services::HAproxy
Manila
The following services configure the OpenStack Shared File Systems service. If separating these services, they need to be part of a Controller systemd role.
# Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::ManilaApi - OS::TripleO::Services::ManilaScheduler
Message Bus
The following services configure the messaging queue. The messaging queue is RabbitMQ managed with Pacemaker.
- name: MessageBus ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::Pacemaker - OS::TripleO::Services::RabbitMQ
Networker
The following services configure the OpenStack Networking agents.
- name: Networker ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::NeutronDhcpAgent - OS::TripleO::Services::NeutronL3Agent - OS::TripleO::Services::NeutronMetadataAgent - OS::TripleO::Services::NeutronOvsAgent
Neutron API
The following services configure the OpenStack Networking API.
- name: NeutronApi ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::NeutronApi - OS::TripleO::Services::NeutronCorePlugin - OS::TripleO::Services::NeutronCorePluginML2OVN - OS::TripleO::Services::NeutronCorePluginMidonet - OS::TripleO::Services::NeutronCorePluginNuage - OS::TripleO::Services::NeutronCorePluginOpencontrail - OS::TripleO::Services::NeutronCorePluginPlumgrid
Nova
The following services configure the OpenStack Compute services.
- name: Nova ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::NovaApi - OS::TripleO::Services::NovaConductor - OS::TripleO::Services::NovaConsoleauth - OS::TripleO::Services::NovaScheduler - OS::TripleO::Services::NovaPlacement - OS::TripleO::Services::NovaVncProxy
Nova Compute
The following services configure an OpenStack Compute node.
- name: Compute ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::CephClient - OS::TripleO::Services::CephExternal - OS::TripleO::Services::ComputeCeilometerAgent - OS::TripleO::Services::ComputeNeutronCorePlugin - OS::TripleO::Services::ComputeNeutronL3Agent - OS::TripleO::Services::ComputeNeutronMetadataAgent - OS::TripleO::Services::ComputeNeutronOvsAgent - OS::TripleO::Services::NeutronOvsAgent - OS::TripleO::Services::NeutronSriovAgent - OS::TripleO::Services::NovaCompute - OS::TripleO::Services::NovaLibvirt - OS::TripleO::Services::OpenDaylightOvs
OpenDaylight
The following services configure OpenDayLight. These services are technology preview for Red Hat OpenStack Platform 11.
- name: Opendaylight ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::OpenDaylightApi - OS::TripleO::Services::OpenDaylightOvs
Redis
The following services configure Redis managed with Pacemaker.
- name: Redis ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::Pacemaker - OS::TripleO::Services::Redis
Sahara
The following services configure the OpenStack Clustering service. If separating these services, they need to be part of a Controller systemd role.
# Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::SaharaApi - OS::TripleO::Services::SaharaEngine
Swift API
The following services configure the OpenStack Object Storage API.
- name: SwiftApi ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::SwiftProxy - OS::TripleO::Services::SwiftRingBuilder
Swift Storage
The following services configure the OpenStack Object Storage service.
- name: ObjectStorage ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::SwiftRingBuilder - OS::TripleO::Services::SwiftStorage
Telemetry
The following services configure the OpenStack Telemetry services.
- name: Telemetry ServicesDefault: # Common Services - OS::TripleO::Services::AuditD - OS::TripleO::Services::CACerts - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::Docker - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::Kernel - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::SensuClient - OS::TripleO::Services::Snmp - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned # Role-Specific Services - OS::TripleO::Services::Apache - OS::TripleO::Services::AodhApi - OS::TripleO::Services::AodhEvaluator - OS::TripleO::Services::AodhListener - OS::TripleO::Services::AodhNotifier - OS::TripleO::Services::CeilometerAgentCentral - OS::TripleO::Services::CeilometerAgentNotification - OS::TripleO::Services::CeilometerApi - OS::TripleO::Services::CeilometerCollector - OS::TripleO::Services::CeilometerExpirer - OS::TripleO::Services::GnocchiApi - OS::TripleO::Services::GnocchiMetricd - OS::TripleO::Services::GnocchiStatsd - OS::TripleO::Services::MongoDb - OS::TripleO::Services::PankoApi
6.6. Composable Service Reference
The following tables contain all composable service available for Red Hat OpenStack Platform 12:
Some services are disabled by default. See Section 6.4.3, “Enabling Disabled Services” for information on how to enable these services.
Service | Description |
---|---|
|
OpenStack Telemetry Alarming ( |
|
OpenStack Telemetry Alarming ( |
|
OpenStack Telemetry Alarming ( |
|
OpenStack Telemetry Alarming ( |
| Apache service configured with Puppet. Note this is typically included automatically with other services which run through Apache. |
| HAProxy service configured with Puppet |
|
OpenStack Telemetry ( |
|
OpenStack Telemetry ( |
|
OpenStack Telemetry ( |
|
OpenStack Telemetry ( |
|
OpenStack Telemetry ( |
| (Disabled by default) Ceph Client service |
| (Disabled by default) Ceph External service |
| (Disabled by default) Ceph Monitor service |
| (Disabled by default) Ceph OSD service |
|
OpenStack Block Storage ( |
|
(Disabled by default) OpenStack Block Storage ( |
|
OpenStack Block Storage ( |
|
OpenStack Block Storage ( |
|
OpenStack Telemetry ( |
|
OpenStack Networking ( |
|
(Disabled by default) OpenStack Networking ( |
|
(Disabled by default) OpenStack Networking ( |
|
OpenStack Networking ( |
| (Disabled by default) Fluentd client configured with Puppet |
|
OpenStack Image ( |
|
OpenStack Telemetry Metrics ( |
|
OpenStack Telemetry Metrics ( |
|
OpenStack Telemetry Metrics ( |
| HAProxy service (Pacemaker-managed) configured with Puppet |
|
OpenStack Orchestration ( |
|
OpenStack Orchestration ( |
|
OpenStack Orchestration ( |
|
OpenStack Orchestration ( |
|
OpenStack Dashboard ( |
|
(Disabled by default) OpenStack Bare Metal Provisioning ( |
|
(Disabled by default) OpenStack Bare Metal Provisioning ( |
| Keepalived service configured with Puppet |
| Load kernel modules with kmod and configure kernel options with sysctl |
|
OpenStack Identity ( |
|
(Disabled by default) OpenStack Shared File Systems ( |
|
(Disabled by default) OpenStack Shared File Systems ( |
|
(Disabled by default) OpenStack Shared File Systems ( |
| Memcached service configured with Puppet |
| MongoDB service deployment using puppet |
| MySQL (Pacemaker-managed) service deployment using puppet |
|
OpenStack Networking ( |
|
OpenStack Networking ( |
|
OpenStack Networking ( |
|
OpenStack Networking ( |
|
OpenStack Networking ( |
|
OpenStack Networking ( |
|
OpenStack Networking ( |
|
OpenStack Networking ( |
|
OpenStack Networking ( |
|
OpenStack Networking ( |
|
OpenStack Networking ( |
|
OpenStack Networking ( |
| (Disabled by default) OpenStack Neutron SR-IOV nic agent configured with Puppet |
|
OpenStack Compute ( |
|
OpenStack Compute ( |
|
OpenStack Compute ( |
|
OpenStack Compute ( |
|
(Disabled by default) OpenStack Compute ( |
| Libvirt service configured with Puppet |
|
OpenStack Compute ( |
|
OpenStack Compute ( |
| NTP service deployment using Puppet. |
| (Disabled by default) OpenDaylight SDN controller |
| (Disabled by default) OpenDaylight OVS configuration |
| Pacemaker service configured with Puppet |
| RabbitMQ service (Pacemaker-managed) configured with Puppet |
| OpenStack Redis service configured with Puppet |
|
(Disabled by default) OpenStack Clustering ( |
|
(Disabled by default) OpenStack Clustering ( |
| (Disabled by default) Sensu client configured with Puppet |
| SNMP client configured with Puppet, to facilitate Ceilometer hardware monitoring in the undercloud. This service is required to enable hardware monitoring. |
|
OpenStack Object Storage ( |
|
OpenStack Object Storage ( |
|
OpenStack Object Storage ( |
| Composable Timezone service |
| Firewall settings |
| Package installation settings |
Service | Description |
---|---|
|
(Disabled by default) Apache service with TLS/SSL enabled. This service is enabled when including Certmonger-based TLS/SSL configuration ( |
|
(Disabled by default) Implements the auditing service. Enabled when including the auditing service environment file ( |
|
(Disabled by default) Ceph Metadata Server (MDS). Enabled when including the Ceph MDS environment file ( |
|
(Disabled by default) Ceph Storage RBD Mirroring service. Enabled when including the RBD Mirroring environment file ( |
|
(Disabled by default) Ceph Storage Object Gateway (radosgw). Enabled when including the RadosGW environment file ( |
|
(Disabled by default) Cinder HPE LeftHand iSCSI backend. Enabled when including the LeftHand iSCSI environment file ( |
|
(Disabled by default) The statistics collection daemon. Enabled when including the Collectd environment file ( |
|
(Disabled by default) OpenStack Policy-as-a-Service (Congress). Enabled when including the Congress environment file ( |
|
(Disabled by default) Etcd key-value storage. Enabled when including the etcd environment file ( |
|
(Disabled by default) Internal network for HAProxy service with TLS/SSL enabled. This service is enabled when including Certmonger-based TLS/SSL configuration ( |
|
(Disabled by default) External network for HAProxy service with TLS/SSL enabled. This service is enabled when including Certmonger-based TLS/SSL configuration ( |
|
(Disabled by default) Manila backend for Ceph Storage. Enabled when including the respective backend environment file ( |
|
(Disabled by default) Generic Manila backend. Enabled when including the respective backend environment file ( |
|
(Disabled by default) Manila backend for NetApp. Enabled when including the respective backend environment file ( |
|
(Disabled by default) OpenStack Workflow Service (mistral) API. Enabled when including the mistral environment file ( |
|
(Disabled by default) OpenStack Workflow Service (mistral) Engine. Enabled when including the mistral environment file ( |
|
(Disabled by default) OpenStack Workflow Service (mistral) Execution server. Enabled when including the mistral environment file ( |
| Database client. |
|
(Disabled by default) Database service with TLS/SSL enabled. This service is enabled when including Certmonger-based TLS/SSL configuration ( |
|
(Disabled by default) Fujitsu C-Fabric plugin for OpenStack network (neutron). Enabled when including the C-Fabric environment file ( |
|
(Disabled by default) Fujitsu fossw plugin for OpenStack network (neutron). Enabled when including the fossw environment file ( |
| OpenStack Compute (nova) metadata service. |
| OpenStack Compute (nova) placement service. |
|
(Disabled by default) OpenStack Load Balancing-as-a-Service (octavia) API. Enabled when including the octavia environment file ( |
|
(Disabled by default) OpenStack Load Balancing-as-a-Service (octavia) Health Manager. Enabled when including the octavia environment file ( |
|
(Disabled by default) OpenStack Load Balancing-as-a-Service (octavia) Housekeeping service. Enabled when including the octavia environment file ( |
|
(Disabled by default) OpenStack Load Balancing-as-a-Service (octavia) Worker service. Enabled when including the octavia environment file ( |
|
(Disabled by default) OVN databases. Enabled when including the OVN extensions ( |
| OpenStack Telemetry Event Storage (panko). |
| (Disabled by default) SSH daemon configuration. Included as a default service. |
|
(Disabled by default) OpenStack NFV Orchestration (tacker). Enabled when including the tacker environment file ( |
|
(Disabled by default) Base service for configuring TLS/SSL. This service is enabled when including Certmonger-based TLS/SSL configuration ( |
|
(Disabled by default) OpenStack Messaging (zaqar). Enabled when including the zaqar environment file ( |