Profile¶
A Profile is a named collection of key/value parameters that can be applied to machines and other objects. Profiles are the primary mechanism for organizing and reusing configuration data across multiple machines without duplicating parameter values.
DRP maintains a special profile named global that acts as the system-wide default parameter source. The global profile has the lowest precedence in the parameter resolution chain. When a template needs a parameter value, DRP searches in this order: machine-specific parameters, the ordered list of profiles on the machine, workorder parameters and profiles, stage parameters and profiles, and finally the global profile. The first match wins.
Profiles can reference other profiles through the Profiles field, enabling profile inheritance and composition. This allows operators to build layered configuration hierarchies. For example, a base OS profile can be combined with an application-specific profile and a site-specific profile to produce a complete configuration.
Profiles are referenced by Machine objects (via an ordered profile list), Stage objects, and Blueprint objects. They work together with Param definitions to provide validated, typed configuration throughout the system.
Metadata¶
| Field | Description | Value |
|---|---|---|
pipeline |
Used to filter user created pipeline Profiles. Do not include with universal-application profiles. Use value from application. |
|
| Create/deletes/manages other machines. | cluster |
|
| Manages the machine assigned. | machine |
|
| The type of pipeline. | application |
|
| Create/deletes/manages other machines. | cluster |
|
| Manages the machine assigned. | machine |
|
platform |
The platform or vendor target for the pipeline. | linode, aws, google, azure |
centos, rocky, ubuntu, esxi, windows |
||
major |
For versioned systems, this identifies major version. | |
minor |
For versioned systems, this identifies minor version. | |
required |
UX form renderer for parameters that must have values. | Example field value |
linode/token,linode/root-password |
||
optional |
UX form renderer for parameters that may have values. | Example field value |
linode/region,linode/instance-type,linode/instance-image,linode/root-password |
Fields¶
| Field | Definition |
|---|---|
| Description | Description is a string for providing a simple description |
| Documentation | Documentation is a string for providing additional in depth information. |
| Meta | Meta contains the meta data of the object. The type of this field is a key / value map/dictionary. The key type is string. The value type is also string. The general content of the field is undefined and can be an arbritary store. There are some common known keys: color - The color the UX uses when displaying icon - The icon the UX uses when displaying * title - The UX uses this for additional display information. Often the source of the object. Specific Object types use additional meta data fields. These are described at: https://docs.rackn.io/stable/redirect/?ref=rs_object_metadata |
| Name | The name of the profile. This must be unique across all profiles. required: true |
| Params | Params holds the values of parameters on the object. The field is a key / value store of the parameters. The key is the name of a parameter. The key is of type string. The value is the value of the parameter. The type of the value is defined by the parameter object. If the key doesn't reference a parameter, the type of the object can be anything. The system will enforce the named parameter's value's type. Go calls the "anything" parameters as "interface {}". Hence, the type of this field is a map[string]interface{}. |
| Profiles | Profiles is an array of profiles to apply to this object in order when looking for a parameter during rendering. |
The profiles are free form dictionaries and default empty. Any key/value pair can be added and referenced.
Other profiles may be created to group parameters together to apply to sets of machines. The machine's profile list allows the administrator to specify an ordered set of profiles that apply to that machine as well.
When the system needs to render a template parameter, the machine's specific parameters are checked, then the order list of profiles stored in the machine object are checked, workorder parameters and profiles are checked, stage parameters and profiles are checked, and finally the global profile is checked. The key and its value are used if found in template rendering. If after all
evaluations are considered, the Parameter object is checked for a default value.
Note
When updating the params section of a profile object, using the API PUT method will replace the Params map with the map from the input object. The API PATCH method will merge the params map in the input with the existing params map in the current profile object. The API POST method on the params subaction will replace the map with the input version.