Blueprint Settings

For an introduction to blueprints, please see the getting started guide. This reference covers the available template attributes that blueprint authors can use, along with some examples. For ease of reading, this reference for blueprint fields is broken down into a few logical sections.


The Blueprint system uses mustache templating under the hood, which is available to operators to specify the Blueprint definitions. This is convenient as it allows users to specify logic-free templates, without perscribing how or where workloads should be deployed. From Nelson’s perspective, it simply applies the template to produce a byte stream, and it sends that to the specified target scheudler, without explicitly knowing anything about the contents.

The renderable attributes typically take the following fashion:

Values

The most simplistic values to render are String and Int. In both of these cases, these simply work by specifying a reference to the field you want to render.

// render a field as a string
stackName: "{{stack_name}}"
// render a numeric field
completions: {{desired_instances}}

Enumerators

Some of the more interesting cases come in the form of an enumerator. In general, these work with a “context block”, which allows you to specify content in terms of key:[item, item].

{{#envvars}}
env:
  {{#envvars_list}}
  - name: "{{envvar_name}}"
    value: "{{envvar_value}}"
  {{/envvars_list}}
{{/envvars}}

In this example, we would say that envvars has the context *, because it can be used anywhere. Comparitivly, the envvars_list can only be used in the context envvars because it is not otherwise accessible.

Units and Deployments

Field Description Context
stack_name The stack name for the given deployment, for example foo--1-2-3--xwsdfsf *
namespace The namespace for the given deployment, for example dev or stage etc *
health_check Block context for everything related to the array of health checks specified in the manifest *
health_check_interval How frequently should we execute this check *
health_check_path What HTTP path should we check for successful response in the event we are probing a HTTP endpoint *
health_check_port What port should the health check attempt to access in the event we are probing a TCP endpoint *
health_check_timeout How long should the specified health check wait before declaring itself failed *
image When Nelson resolves the actual image that should be used for this deployment at runtime, its value will be populated into this field. This image name will always be a fully-qualified name adhering to the Docker image specification for repositories and tags *
port_name Human-readable label for a given port, ascribed in the manifest. For example, default or http etc ports_list
port_number Integer number corresponding to the port declared in the manifest file for a given label. ports_list
ports Block context for everything related to the array of ports specified in the manifest *
ports_list Handle for traversing the port list, and accessing the port_number and port_name fields ports
unit_name Name of the unit you are attempting to deploy. For example foo or foo-bar. Never includes spaces or special characters and must adher to sanitization per ITEF RFC 1035 *
version The version of this particular unit being deployed. Typically a semantic version of the form 1.2.3, 4.53.44 etc *

Plans

Field Description Context
cpu_limit If supported by your scheudler, what is the maximum number of CPUs tasks derived from this blueprint should be able to use *
cpu_request If supported by your scheudler, what is the minimum number of CPUs tasks derived from this blueprint should be able to use *
desired_instances How many copies of the container should the scheudler attempt to run. *
empty_volume_mount_name What should the logical name of the volume mount be empty_volumes_list
empty_volume_mount_path What filesystem path should the volume be mounted too empty_volumes_list
empty_volume_mount_size How large should the specified volume be, defined in megabytes empty_volumes_list
empty_volumes Block context for everything related to the array of volumes specified in the manifest *
empty_volumes_list Handle for traversing the port list, and accessing the empty_volume_mount_size, empty_volume_mount_name and empty_volume_mount_path fields empty_volumes
envvar_name The name of the specified environment variable envvars_list
envvar_value The value ascribed to a given environment variable envvars_list
envvars Block context for everything related to the array of environment variables specified in the manifest file *
envvars_list Handle for traversing the environment variable list, and accessing the envvar_name and envvar_value fields envvars
memory_limit If supported by your scheudler, what is the maximum amount of memory tasks derived from this blueprint should be allocated *
memory_request If supported by your scheudler, what is the minimum amount of memory tasks derived from this blueprint should be allocated *
retries In the event the container fails to launch, how many times should the scheudler retry before giving up attempting to scheudle the task deriving from this blueprint *
schedule If the deployment in question had a cron-style scheudle defined in its plan, then this field will hold that value. *