Templates

Templates defined rendered data in the DRP content ecosystem.

Usages

Templates are used in multiple places:

• Tasks templates (in-line or as separate object)
  • As files in the runner's filesystem
  • As scripts to execute by the runner
• Bootenvs / Stages templates (in-line or as separate objects)
  • As files that are servered by the DRP Endpoint for remote systems to access
  • E.g. Anaconda kickstart files or cloud-init meta-data/user-data files
• Param expansion templates
  • As data inside a parameter to allow parameter indirection or minor data manipulation
  • E.g. ipmi/configure/username: '{{.ParamExpand "my-other-parameter-with-username"}}'
• Subnet options
  • Subnet options can have expansions to handle DHCP option processing.
  • This is highly restricted set of rendering options.

Template Object versus Templates

The Template object is used by the content system to track a named template. These can be used in TemplateInfo structures of Tasks, Stage, or BootEnv by reference.

Additionally, template objects can be referenced by the .CallTemplate and template template functions. These name used as the first parameter must be a valid template object in the system.

The Template Object is not directly referencable in a Subnet DHCP option or a parameter expansion. These would have to use the .CallTemplate or template function inside the in-line template.

Basic Layout

The basic template is a text string. Encoding doesn't really matter and can vary by usage. The text can be multi-line if needed by the application.

The template is a golang text template. The default template delimiters are {{ and }}. For task templates, this can be altered, but should only be done with care.

With in the delimiters, the default functions from golang are augmented by the Mastermind Sprig library. For security reasons, functions altering the local filesystem or local networking functions are disabled.

In addition, the DRP Endpoint includes additional functions defined in the Template.

Parameter Rendering

The main strength of the template system is to render parameters by the template system to generate dynamic data. Parameter Rendering describes the ways and functions to render parameters.

Quick Reference: Parameter Rendering Functions

.Param, .ParamExpand, .ParamCompose, .ParamComposeExpand comparison table.

Aspect	.Param	.ParamExpand	.ParamCompose	.ParamComposeExpand
Primary Behavior	Returns the raw parameter value.	Expands the parameter value as a template.	Composes/merges parameter values (lists, maps) into a single result without template evaluation.	Composes/merges parameter values and also evaluates embedded templates.
Error Handling	Missing parameters fall back to defaults or error.	Warning: fails if expansion references malformed templates or parameters missing defaults.	Merges defined values, missing values skipped.	Warning: failures can occur if composed values contain broken templates.
Default Propagation	Normal — defaults flow as expected.	Warning — chained defaults may fail if reference lacks a default.	Normal — list/map defaults merge predictably.	Warning — fails if composed template values depend on missing defaults.
.ParamExists Behavior	Accurate — true only if parameter is defined.	Misleading — may return true even if rendering later fails.	Accurate — reflects defined composed values.	Misleading — passes existence check, but composed rendering can still fail.
Type Validation	Enforces schema types.	Deferred/ignored until render.	Respects type (list/map composition validated).	Type validation weakened until render; template expansion can bypass checks.
Typical Issue Example	N/A	Template expansion failure or missing chained defaults.	Safe merge: list defaults + overrides.	Template inside list entry fails expansion due to missing param.
Safe Usage Scenarios	Standard parameter lookups.	Indirect parameter referencing or dynamic values	Building aggregated lists or maps from multiple defaults/overrides.	Building aggregated structures that also need parameter indirection or dynamic values.
Risks	Minimal: Missing defaults	Low: late render failures, missing defaults.	Low: unclear parameter ordering	Medium: Missing defaults, unclear parameter ordering
Best Practice	Simple parameter case	Use with parameter defaults.	Use for structured params (lists/maps) that need composition.	Use cautiously for structured params that also need embedded template expansion.

Summary

• .Param → Safe, raw lookup.
• .ParamExpand → Use for parameter indirection on parameters with defaults.
• .ParamCompose → Safe, for building lists/maps (structured params).
• .ParamComposeExpand → Powerful but fragile: merges structured params and expands templates. Use only when necessary, with strict defaults.