Glossary
Terminology from TOSCA
Service Template
Services templates specify how resources should be configured using the TOSCA standard. Templates can live in their own git repositories.
Node Template
A Node Template specifies the occurrence of a component node as part of a Topology Template. Each Node Template refers to a Node Type that defines the semantics of the node (e.g., properties, attributes, requirements, capabilities, interfaces). Node Types are defined separately for reuse purposes.
Entity Types
Every entity in TOSCA (including Nodes, Relationships, Artifacts and Data) has a declared type and custom type hierarchies can be defined in the Service Template.
Instance
The running instance of a Node Template, typically instantiated when running the deployment workflow.
Properties
Name values that are declared in the specification of the node and relationship templates.
Attributes
Attribute refer to the actual values of an instance. They may be a reflect declared properties’ values or they may be determined at runtime.
Topology
The set of Node Template and Relationship Template definitions that together define the topology model of a service as a (not necessarily connected) directed graph.
Relationships and Requirements
Relationships between nodes are specified in the requirements section of a node template.
Relationship Template
Specifies the occurrence of a relationship between nodes in a Topology Template. Each Relationship Template refers to a Relationship Type that defines the semantics relationship (e.g., properties, attributes, interfaces, etc.). Relationship Types are defined separately for reuse purposes.
Capabilities
Nodes can specify the types of capabilities they may have and the relationships between nodes can target specific capabilities.
Operation
The basic unit of work invoked by an TOSCA orchestrator such as Unfurl. Interfaces associated with TOSCA types define a collections of operations and Node and Relationship templates specify their implementation.
Workflow
A plan for executing operations on instances. Predefined workflows include deploy for instantiating a topology, undeploy for destroying it, discover for discovering existing instances, and check for checking the status of existing instances. Custom workflows can be defined in a service template.
Unfurl specific
Ensembles
A representation of an isolated collections of resources. Ensembles are implemented in manifest files that describe the resources’ operations, properties and current state. Ensembles can lives in its own git repository, maintaining a history of changes applied to its resources.
Configurators
A software plugin that implements an operation. Configurators apply changes to instances. There are built-in configurators for shell scripts, Ansible playbooks, Terraform configurations, and Kubernetes resources or you can include your as part of the service specification.
Installations
Installation can create and update many instances as a side effect of its operation and only the important ones need to be reified. See Helm Release as an example installation.
Installers
A node template represents the software that creates and manages installations. Installers allow implementations to be reified as first-class instances so they can be instantiated and configured themselves, enabling the local client environment to be bootstrapped as well.
Eval expressions
YAML markup that is evaluated when running a job.
Job
A jobs executes a workflow by instantiating a plan of tasks to run.
Tasks
Instantiates a configurator to carry out the given operation.
Config Change
A persistent record of the changes made by a task.
Changelog
A YAML file that describes job run with the changes made to the ensemble.
Secrets
An object that represents a secret value. Secrets are stored in a separate configuration file outside of version control or retrieved from a KMS such as Hashicorp Vault. Sensitive values and objects tainted by sensitive values are always redacted when serialized or logged.
Local values
Values and configurations settings that are dependent on the local environment and therefore should be saved separately from a shared repository or deployment history. For example, connection or proxy settings. Marking which settings are local helps enable a reproducible infrastructure.
External values
Values that are not directly serialized into the model but rather referenced by a name that is resolved during task execution. Examples are secrets, local values, file references, and external (imported) instances. External values can indicate if they’ve changed and so can participate in incremental updates of the ensemble.
External instances
External instances are instances that are part of a separate ensemble. They are only accessible through the External expression function unless the service template has corresponding node template with a
selectorsubstitutedirective.