Firstboot configuration is optional, and is performed on all nodes on initial
deployment.

Any configuration possible via cloud-init may be performed at this point,
either by applying cloud-config yaml or running arbitrary additional
scripts.

The heat templates used for deployment provide the OS::TripleO::NodeUserData
resource as the interface to enable this configuration. A basic example of its
usage is provided below, followed by some notes related to real world
usage.

The script snippet below shows how to create a simple example containing two
scripts, combined via the MultipartMime resource:

Make sure you pass the same environment parameters that were used at
deployment time in addition to your customization environments at the
end (userdata_env.yaml).

Note

The userdata is applied to all nodes in the deployment. If you need role
specific logic, the userdata scripts can contain conditionals which use
e.g the node hostname to determine the role.

Note

OS::TripleO::NodeUserData is only applied on initial node deployment,
not on any subsequent stack update, because cloud-init only processes the
nova user-data once, on first boot. If you need to add custom configuration
that runs on all stack creates and updates, see the
Post-Deploy extra configuration section below.

For a more complete example, which creates an additional user and configures
SSH keys by accessing the nova metadata server, see
/usr/share/openstack-tripleo-heat-templates/firstboot/userdata_example.yaml
on the undercloud node or the tripleo-heat-templates repo.

This configuration happens after any “firstboot” configuration is applied,
but before any Post-Deploy configuration takes place.

Typically these interfaces are suitable for preparing each node for service
deployment, such as registering nodes with a content repository, or creating
additional data to be consumed by the post-deploy phase. They may also be suitable
integration points for additional third-party services, drivers or plugins.

The “server” parameter must be specified in all per-node ExtraConfig templates,
this is the server to apply the configuration to, and is provided by the parent
template. Optionally additional implementation specific parameters may also be
provided by parameter_defaults, see below for more details.

Any resources may be defined in the template, but the outputs must define a “deploy_stdout”
value, which is an identifier used to detect if the configuration applied has changed,
hence when any post-deploy actions (such as re-applying puppet manifests on update)
may need to be performed.

For a more complete example showing how to apply a personalized map of per-node configuration
to each node, see /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/per_node.yaml
or the tripleo-heat-templates repo.

Post-deploy additional configuration is possible via the
OS::TripleO::NodeExtraConfigPost interface, which is applied after any
per-node configuration has completed.

Note

The OS::TripleO::NodeExtraConfigPost applies configuration to all nodes,
there is currently no per-role NodeExtraConfigPost interface.

Below is an example of a post-deployment configuration template:

mkdir-pextraconfig/post-deploy/cat>extraconfig/post-deploy/example.yaml<<EOFheat_template_version:2014-10-16parameters:servers:type:json# Optional implementation specific parameterssome_extraparam:type:stringresources:ExtraConfig:type:OS::Heat::SoftwareConfigproperties:group:scriptconfig:str_replace:template:|#!/bin/shecho"extra _APARAM_">/root/extraparams:_APARAM_:{get_param:some_extraparam}ExtraDeployments:type:OS::Heat::SoftwareDeploymentGroupproperties:servers:{get_param:servers}config:{get_resource:ExtraConfig}actions:['CREATE']# Only do this on CREATEEOF

The “servers” parameter must be specified in all NodeExtraConfigPost
templates, this is the server list to apply the configuration to,
and is provided by the parent template.

Optionally, you may define additional parameters which are consumed by the
implementation. These may then be provided via parameter_defaults in the
environment which enables the configuration.

Note

If the parameter_defaults approach is used, care must be used to avoid
unintended reuse of parameter names between multiple templates, because
parameter_defaults is applied globally.

The “actions” property of the OS::Heat::SoftwareDeploymentGroup resource may be
used to specify when the configuration should be applied, e.g only on CREATE,
only on DELETE etc. If this is omitted, the heat default is to apply the
config on CREATE and UPDATE, e.g on initial deployment and every subsequent
update.