Chapter 6. Composable services
Red Hat OpenStack Platform (RHOSP) includes the ability to define custom roles and compose service combinations on roles. For more information, see {defaultURL}/advanced_overcloud_customization/chap-roles[Composable Services and Custom Roles] in the Advanced Overcloud Customization guide. As part of the integration, you can define your own custom services and include them on chosen roles.
6.1. Examining composable service architecture
The core heat template collection contains two sets of composable service templates:
-
puppet/services
contains the base templates for configuring composable services. -
docker/services
contains the containerized templates for key OpenStack Platform services. These templates act as augmentations for some of the base templates and reference back to the base templates.
Each template contains a description that identifies its purpose. For example, the ntp.yaml
service template contains the following description:
description: > NTP service deployment using puppet, this YAML file creates the interface between the HOT template and the puppet manifest that actually installs and configure NTP.
These service templates are registered as resources specific to a RHOSP 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.
Some resources use the base composable service templates directly:
resource_registry: ... OS::TripleO::Services::Ntp: puppet/services/time/ntp.yaml ...
However, core services require containers and as such use the containerized service templates. For example, the keystone
containerized service uses the following:
resource_registry: ... OS::TripleO::Services::Keystone: docker/services/keystone.yaml ...
These containerized templates usually reference back to the base templates in order to include Puppet configuration. For example, the docker/services/keystone.yaml
template stores the output of the base template in the KeystoneBase
parameter:
KeystoneBase: type: ../../puppet/services/keystone.yaml
The containerized template can then incorporate functions and data from the base template.
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.2. Creating a user-defined composable service
This example examines how to create a user-defined composable service and focuses on implementing a message of the day (motd
) service. In this example, the overcloud image contains a custom motd
Puppet module loaded either through a configuration hook or through modifying the overcloud images. For more information, see Chapter 3, Working with overcloud images.
When you create your own service, you must define the following items in the heat template of your service:
- parameters
The following are compulsory parameters that you must include in your service template:
-
ServiceNetMap
- A map of services to networks. Use an empty hash ({}
) as thedefault
value as this parameter is overriden with values from the parent Heat template. -
DefaultPasswords
- A list of default passwords. Use an empty hash ({}
) as thedefault
value as this parameter is overriden with values from the parent Heat template. -
EndpointMap
- A list of OpenStack service endpoints to protocols. Use an empty hash ({}
) as thedefault
value as this parameter is overriden with values from the parent Heat template.
Define any additional parameters that your service requires.
-
- outputs
- The following output parameters define the service configuration on the host. For more information, see Appendix A, Composable service parameters.
The following is an example heat template (service.yaml
) for the motd
service:
heat_template_version: 2016-04-08 description: > Message of the day service configured with Puppet parameters: ServiceNetMap: default: {} type: json DefaultPasswords: default: {} type: json EndpointMap: default: {} type: json MotdMessage: 1 default: | Welcome to my Red Hat OpenStack Platform environment! type: string description: The message to include in the motd outputs: role_data: description: Motd role using composable services. value: service_name: motd config_settings: 2 motd::content: {get_param: MotdMessage} step_config: | 3 if hiera('step') >= 2 { include ::motd }
- 1
- The template includes a
MotdMessage
parameter that defines the message of the day. The parameter includes a default message but you can override it by using the same parameter in a custom environment file. - 2
- The
outputs
section defines some service hieradata inconfig_settings
. Themotd::content
hieradata stores the content from theMotdMessage
parameter. Themotd
Puppet class eventually reads this hieradata and passes the user-defined message to the/etc/motd
file. - 3
- The
outputs
section includes a Puppet manifest snippet instep_config
. The snippet checks if the configuration has reached step 2 and, if so, runs themotd
Puppet class.
6.3. Including a user-defined composable services
You can configure the custom motd service only on the overcloud Controller nodes. This requires a custom environment file and custom roles data file included with your deployment. Replace example input in this procedure according to your requirements.
Procedure
Add the new service to an environment file,
env-motd.yaml
, as a registered heat resource within theOS::TripleO::Services
namespace. In this example, the resource name for ourmotd
service isOS::TripleO::Services::Motd
:resource_registry: OS::TripleO::Services::Motd: /home/stack/templates/motd.yaml parameter_defaults: MotdMessage: | You have successfully accessed my Red Hat OpenStack Platform environment!
This custom environment file also includes a new message that overrides the default for
MotdMessage
.The deployment now includes the
motd
service. However, each role that requires this new service must have an updatedServicesDefault
listing in a customroles_data.yaml
file.Create a copy of the default
roles_data.yaml
file:$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/custom_roles_data.yaml
To edit this file, scroll to the
Controller
role and include the service in theServicesDefault
listing:- name: Controller CountDefault: 1 ServicesDefault: - OS::TripleO::Services::CACerts - OS::TripleO::Services::CephMon - OS::TripleO::Services::CephExternal ... - OS::TripleO::Services::FluentdClient - OS::TripleO::Services::VipHosts - OS::TripleO::Services::Motd # Add the service to the end
When you create an overcloud, include the resulting environment file and the
custom_roles_data.yaml
file with your other environment files and deployment options:$ openstack overcloud deploy --templates -e /home/stack/templates/env-motd.yaml -r ~/custom_roles_data.yaml [OTHER OPTIONS]
This includes our custom motd
service in our deployment and configures the service on Controller nodes only.