Dissecting TripleO service templates (part 4)
by Juan Antonio Osorio Robles
In this series of blog posts, I’ve been covering all the different sections of the service templates for TripleO.
On the first part I covered the bare-minimum sections you need for your template.
On the second part I covered the sections that allow you to use Ansible to write and customize your service.
On the third part I covered the sections that allow you to write a containerized service for TripleO.
Here I cover “the rest”.
TripleO offers a lot of options to modify and configure your services, with all this flexibility, we have needed to covered different common cases, and other not so common cases. And it is also worth noting that TripleO is meant to manage your day 2 operations for your OpenStack cloud, so this also needs to be covered by TripleO.
Now that you know the basics, lets briefly cover the more advanced sections of the service templates.
The overall view
While looking at other service templates is a good way to see what’s being done and how one can do things. If you want to know all the available options, there is actually a file where this is gathered: common/services.yaml
Here you’ll find where the ResourceChain is called, so from this you can derive the mandatory parameters from the templates. You’ll also find what outputs are gathered and how.
With this in mind, we can now continue and dive in the rest of the sections. Given the diversity of the outputs that are left to cover; I’ll try to divide them in sections.
Extra hieradata options
These options, similarly to the
config_settings section mentioned in part
1, set up
appropriate hieradata, however, their usage and behavior varies.
config_settings sets up hieradata for the role where the service is
global_config_settings allows you to output the needed hieradata
in all nodes of the cluster.
Allows you to output hieradata to wherever a certain service is configured. This is specially useful if your service can be a backend for another service. Lets take Barbican as an example:
In this case, the Barbican service template explicitly configures the
cinder_api services by setting hieradata to wherever
they’re at. This way, if someone enables barbican, we automatically enable the
volume encryption feature.
These sections belong to the update workflow, which is an update within the same version (passing from one version to another is called an upgrade).
Similarly to the
deploy_steps_tasks mentioned in part 2, these are
Ansible tasks that run on the node. However, these run as part of the updates
workflow at the beginning of the Ansible run. So, if you’re acquainted with
this workflow, these run at the beginning of the
openstack overcloud update
run command, which runs the Ansible playbook for updates. After this,
host_prep_tasks and subsequently
deploy_step_tasks run. Finalizing with
To summarize, if your application needs to execute some actions when a minor update is executed, which needs to happen before the TripleO steps, then you need this section.
As mentioned in the previous section, this runs at the end of the minor update workflow. You might need this section for your service if you need to execute some ansible tasks after the TripleO steps.
While at the time of writing this no service is using this section, it might
prove to me useful at some point. This is fairly similar to the
update_tasks section, except that this runs on the node that runs the
playbook (typically the undercloud). So, it also runs before the TripleO steps
as part of the updates workflow. This is meant for services that are deployed
external_deploy_tasks section, which was mentioned in part 2.
These sections belong to the upgrade workflow. Similarly to the update workflow mentioned before, this is also powered via Ansible and has a similar call path, with actions that run before and after the steps.
update_tasks, this runs before the TripleO steps, but in the
post_update_tasks, this runs after the TripleO steps, but in
the upgrade workflow.
external_update_tasks, this runs before the TripleO steps, but
in the host that’s calling the ansible playbook and on the upgrade workflow.
This runs before
upgrade_tasks (which already runs before the TripleO
steps) and is be executed in a node-by-node rolling fashion at the beginning of
the major upgrade workflow.
This is quite a special case, where you need to take special care and do so in a node-by-node fashion, such as was the case when upgrading the neutron services on to containerized services. This made sure that instance connectivity wasn’t lost.
Fast Forward upgrades options
The following sections belong to the Fast forward upgrades
workflow, which updates from one release up to 3 releases
N -> N+3).
These are carried in steps, but are also carried by release. So moving from release to release, you’ll need to specify which tasks are executed for what release, and in what step of the deployment they’re executed.
There is a maximum of 9 steps, of which the loops are divided into two categories.
From steps 0 to 3, these are considered prep tasks, so they’re ran on all nodes containing that service.
After this, from steps 4 to 9, these are bootstrap tasks, so they’re ran only on one node that contains the service.
Similarly to the updates and upgrades
_post_*_tasks sections, this runs
after the TripleO steps on the FFU ugprades and does certain ansible tasks.
In synergy with the
external_deploy_tasks section described in part 2, and
similarly to other
executes ansible tasks on the node that runs the Ansible playbook, and this
happens after the TripleO steps.
This is used for sensu integration. For all of the services, the subscription names will be gathered and set up for the sensu client susbcriptions.
This belongs to the TLS everywhere workflow and is better described in the developer documentation. But, in a nutshell, this controls how the service principals are created in FreeIPA via novajoin. Eventually this information gets passed from the templates via nova-metadata to the novajoin vendordata plugin, which subsequently calls FreeIPA and generates the necessary service principals.
This section is meant to create scripts that will be persisted in the
/var/lib/docker-config-scripts directory. It takes the following options:
mode: The mode number that defines the file permissions.
content the actual content of the script.
Allows you to execute Mistral actions or workflows for a specific service. It was primarily used by Ceph when it was introduced, but it changed to use Ansible directly instead.
An example would be the following:
This is meant to be a boolean flag that indicates if a node should be considered for cellv2 discovery. Mostly, the nova-compute and ironic services set this flag in order for t-h-t to consider add them to the list of nodes. Chances are, you don’t need to set this flag at all, unless you do a service that overwrites the nova-compute service.
Deprecated or unused parameters
Finally, the following parameters are deprecated, set or set for deprecation. I’m adding them here in case you have Queens or newer templates, and with hopes they don’t confuse you.
The following commands used to be for fluentd integration:
These are no longer used, and instead, this integration is now done via hieradata directly.
tags: tripleo - openstack