· attribute_definitions: represents the optional map of attribute_definitions for the Group Type.
· property_definitions: represents the optional map of property definitions for the Group Type.
· list_of_valid_member_types: represents the optional list of TOSCA types (e.g.,., Node, Capability or even other Group Types) that are valid member types for being added to (i.e., members of) the Group Type.
Note that earlier versions of this specification support interface definitions, capability definitions, and requirement definitions in group types. These definitions have been deprecated in this version based on the realization that groups in TOSCA only exist for purposes of uniform application of policies to collections of nodes. Consequently, groups do not have a lifecycle of their own that is independent of the lifeycle of their members.
· Group definitions SHOULD NOT be used to define or redefine relationships (dependencies) between nodes that can be expressed using normative TOSCA Relationships (e.g., HostedOn, ConnectsTo, etc.) within a TOSCA topology template.
· The list of values associated with the “members” keyname MUST only contain types that or homogenous (i.e., derive from the same type hierarchy).
The following represents a Group Type definition:
|
group_types: mycompany.mytypes.groups.placement: description: My company’s group type for placing nodes of type Compute members: [ tosca.nodes.Compute ] |
A Policy Type defines a type of requirement that affects or governs an application or service’s topology at some stage of its lifecycle, but is not explicitly part of the topology itself (i.e., it does not prevent the application or service from being deployed or run if it did not exist).
The Policy Type is a TOSCA Entity and has the common keynames listed in section 3.7.1 TOSCA Entity Schema.
In addition, the Policy Type has the following recognized keynames:
|
Keyname |
Required |
Type |
Description |
|
properties |
no |
map of |
An optional map of property definitions for the Policy Type. |
|
targets
|
no |
string[] |
An optional list of valid Node Types or Group Types the Policy Type can be applied to.
Note: This can be viewed by TOSCA Orchestrators as an implied relationship to the target nodes, but one that does not have operational lifecycle considerations. For example, if we were to name this as an explicit Relationship Type we might call this “AppliesTo” (node or group). |
|
triggers |
no |
map of trigger definitions |
An optional map of policy triggers for the Policy Type. |
Policy Types have the following grammar:
|
derived_from: <parent_policy_type_name> version: <version_number> metadata: description: <policy_description> properties: targets: [ <list_of_valid_target_types> ] triggers: |
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
· policy_type_name: represents the required symbolic name of the Policy Type being declared as a string.
· parent_policy_type_name: represents the name (string) of the Policy Type this Policy Type definition derives from (i.e., its “parent” type).
· version_number: represents the optional TOSCA version number for the Policy Type.
· policy_description: represents the optional description string for the corresponding policy_type_name.
· property_definitions: represents the optional map of property definitions for the Policy Type.
· list_of_valid_target_types: represents the optional list of TOSCA types (i.e., Group or Node Types) that are valid targets for this Policy Type.
· trigger_definitions: represents the optional map of trigger definitions for the policy.
The following represents a Policy Type definition:
|
policy_types: mycompany.mytypes.policies.placement.Container.Linux: description: My company’s placement policy for linux derived_from: tosca.policies.Root |
The definitions in this section provide reusable modeling element grammars that are specific to the Node or Relationship templates.
A capability assignment allows node template authors to assign values to properties and attributes for a named capability definition that is part of a Node Template’s type definition.
The following is the list of recognized keynames for a TOSCA capability assignment:
|
Keyname |
Required |
Type |
Description |
|
properties |
no |
map of |
An optional map of property definitions for the Capability definition. |
|
attributes |
no |
map of |
An optional map of attribute definitions for the Capability definition. |
|
occurrences |
no |
An optional range that further refines the minimum and maximum occurrences specified in the corresponding capability definition. If no range is specified, the range from the corresponding capability definition is used. |
Capability assignments have one of the following grammars:
|
properties: attributes: occurrences: [ min_occurrences, max_occurrences ] |
In the above grammars, the pseudo values that appear in angle brackets have the following meaning:
· capability_definition_name: represents the symbolic name of the capability as a string.
· property_assignments: represents the optional map of property assignments for the capability definition.
· attribute_assignments: represents the optional map of attribute assignments for the capability definition.
· min_occurrences, max_occurrences: lower and upper bounds of the range that further refines the minimum and maximum occurrences for this capability specified in the corresponding capability definition. The range specified here must fall completely within the occurrences range specified in the corresponding capability definition
The following example shows a capability assignment:
|
node_templates: some_node_template: capabilities: some_capability: properties: limit: 100 |
A Requirement assignment allows template authors to provide either concrete names of TOSCA templates or provide abstract selection criteria for providers to use to find matching TOSCA templates that are used to fulfill a named requirement’s declared TOSCA Node Type.
The following is the list of recognized keynames for a TOSCA requirement assignment:
|
Keyname |
Required |
Type |
Description |
|
capability |
no |
The optional reserved keyname used to provide the name of either a: · Capability definition within a target node template that can fulfill the requirement. · Capability Type that the provider will use to select a type-compatible target node template to fulfill the requirement at runtime. |
|
|
node |
no |
The optional reserved keyname used to identify the target node of a relationship. specifically, it is used to provide either a: · Node Template name that can fulfill the target node requirement. · Node Type name that the provider will use to select a type-compatible node template to fulfill the requirement at runtime. |
|
|
relationship |
no |
The optional reserved keyname used to provide the name of either a: · Relationship Template to use to relate the source node to the (capability in the) target node when fulfilling the requirement. · Relationship Type that the provider will use to select a type-compatible relationship template to relate the source node to the target node at runtime. |
|
|
node_filter |
no |
The optional filter definition that TOSCA orchestrators or providers would use to select a type-compatible target node that can fulfill the associated abstract requirement at runtime. |
|
|
occurrences |
no |
An optional range that further refines the optional minimum and maximum occurrences for this requirement. If no range is specified, the range from the corresponding requirement definition is used. |
The following is the list of recognized keynames for a TOSCA requirement assignment’s relationship keyname which is used when property assignments or inputs of declared interfaces (or their operations) need to be provided:
|
Keyname |
Required |
Type |
Description |
|
type |
no |
The optional reserved keyname used to provide the name of the Relationship Type for the requirement assignment’s relationship keyname. |
|
|
properties |
no |
map of |
An optional map of property assignments for the relationship. |
|
interfaces |
no |
map of |
The optional reserved keyname used to reference declared (named) interface definitions of the corresponding Relationship Type in order to provide Property assignments for these interfaces or operations of these interfaces. |
Named requirement assignments have one of the following grammars:
The following single-line grammar may be used if only a concrete Node Template for the target node needs to be declared in the requirement:
This notation is only valid if the corresponding Requirement definition in the Node Template’s parent Node Type declares (at a minimum) a valid Capability Type which can be found in the declared target Node Template. A valid capability definition always needs to be provided in the requirement declaration of the source node to identify a specific capability definition in the target node the requirement will form a TOSCA relationship with.
The following grammar would be used if the requirement assignment needs to provide more information than just the Node Template name:
|
node: <node_template_name> | <node_type_name> relationship: <relationship_template_name> | <relationship_type_name> capability: <capability_symbolic_name> | <capability_type_name> node_filter: occurrences: [ min_occurrences, max_occurrences ] |
The following additional multi-line grammar is provided for the relationship keyname in order to provide new Property assignments for inputs of known Interface definitions of the declared Relationship Type.
|
# Other keynames omitted for brevity relationship: type: <relationship_template_name> | <relationship_type_name> properties: interfaces: |
Examples of uses for the extended requirement assignment grammar include:
· The need to allow runtime selection of the target node based upon an abstract Node Type rather than a concrete Node Template. This may include use of the node_filter keyname to provide node and capability filtering information to find the “best match” of a concrete Node Template at runtime.
· The need to further clarify the concrete Relationship Template or abstract Relationship Type to use when relating the source node’s requirement to the target node’s capability.
· The need to further clarify the concrete capability (symbolic) name or abstract Capability Type in the target node to form a relationship between.
· The need to (further) constrain the occurrences of the requirement in the instance model.
In the above grammars, the pseudo values that appear in angle brackets have the following meaning:
· requirement_name: represents the symbolic name of a requirement assignment as a string.
· node_template_name: represents the optional name of a Node Template that contains the capability this requirement will be fulfilled by.
· relationship_template_name: represents the optional name of a Relationship Template to be used when relating the requirement appears to the capability in the target node.
· capability_symbolic_name: represents the required named capability definition within the target Node Type or Template.
· node_type_name: represents the optional name of a TOSCA Node Type the associated named requirement can be fulfilled by. This must be a type that is compatible with the Node Type declared on the matching requirement (same symbolic name) the requirement’s Node Template is based upon.
· relationship_type_name: represents the optional name of a Relationship Type that is compatible with the Capability Type in the target node.
· property_assignments: represents the optional map of property value assignments for the declared relationship.
· interface_assignments: represents the optional map of interface definitions for the declared relationship used to provide property assignments on inputs of interfaces and operations.
· capability_type_name: represents the optional name of a Capability Type definition within the target Node Type this requirement needs to form a relationship with.
· node_filter_definition: represents the optional node filter TOSCA orchestrators would use to fulfill the requirement for selecting a target node. Note that this SHALL only be valid if the node keyname’s value is a Node Type and is invalid if it is a Node Template.
A web application node template named ‘my_application_node_template’ of type WebApplication declares a requirement named ‘host’ that needs to be fulfilled by any node that derives from the node type WebServer.
|
# Example of a requirement fulfilled by a specific web server node template node_templates: my_application_node_template: type: tosca.nodes.WebApplication ... requirements: - host: node: tosca.nodes.WebServer |
In this case, the node template’s type is WebApplication which already declares the Relationship Type HostedOn to use to relate to the target node and the Capability Type of Container to be the specific target of the requirement in the target node.
This example is similar to the previous example; however, the requirement named ‘database’ describes a requirement for a connection to a database endpoint (Endpoint.Database) Capability Type in a named node template (my_database). However, the connection requires a custom Relationship Type (my.types.CustomDbConnection’) declared on the keyname ‘relationship’.
|
# Example of a (database) requirement that is fulfilled by a node template named # “my_database”, but also requires a custom database connection relationship my_application_node_template: requirements: - database: node: my_database capability: Endpoint.Database relationship: my.types.CustomDbConnection |
This example shows how to extend an abstract ‘host’ requirement for a Compute node with a filter definition that further constrains TOSCA orchestrators to include additional properties and capabilities on the target node when fulfilling the requirement.
|
node_templates: mysql: type: tosca.nodes.DBMS.MySQL properties: # omitted here for brevity requirements: - host: node: tosca.nodes.Compute node_filter: capabilities: - host: properties: - num_cpus: { in_range: [ 1, 4 ] } - mem_size: { greater_or_equal: 512 MB } - os: properties: - architecture: { equal: x86_64 } - type: { equal: linux } - distribution: { equal: ubuntu } - mytypes.capabilities.compute.encryption: properties: - algorithm: { equal: aes } - keylength: { valid_values: [ 128, 256 ] } |
A Node Template specifies the occurrence of a manageable software component as part of an application’s topology model which is defined in a TOSCA Service Template. A Node template is an instance of a specified Node Type and can provide customized properties, constraints or operations which override the defaults provided by its Node Type and its implementations.
The following is the list of recognized keynames for a TOSCA Node Template definition:
|
Keyname |
Required |
Type |
Description |
|
type |
yes |
The required name of the Node Type the Node Template is based upon. |
|
|
description |
no |
An optional description for the Node Template. |
|
|
metadata |
no |
Defines a section used to declare additional metadata information. |
|
|
directives |
no |
string[] |
An optional list of directive values to provide processing instructions to orchestrators and tooling. |
|
properties |
no |
map of |
An optional map of property value assignments for the Node Template. |
|
attributes |
no |
map of |
An optional map of attribute value assignments for the Node Template. |
|
requirements |
no |
list of |
An optional list of requirement assignments for the Node Template. |
|
capabilities |
no |
map of |
An optional map of capability assignments for the Node Template. |
|
interfaces |
no |
map of |
An optional map of named interface definitions for the Node Template. |
|
artifacts |
no |
map of
|
An optional map of named artifact definitions for the Node Template. |
|
node_filter |
no |
The optional filter definition that TOSCA orchestrators would use to select the correct target node. |
|
|
copy |
no |
The optional (symbolic) name of another node template to copy into (all keynames and values) and use as a basis for this node template. |
|
type: <node_type_name> description: <node_template_description> directives: [<directives>] metadata: properties: attributes: requirements: capabilities: interfaces: artifacts: node_filter: copy: <source_node_template_name> |
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
· node_template_name: represents the required symbolic name of the Node Template being declared.
· node_type_name: represents the name of the Node Type the Node Template is based upon.
· node_template_description: represents the optional description string for Node Template.
· directives: represents the optional list of processing instruction keywords (as strings) for use by tooling and orchestrators.
· property_assignments: represents the optional map of property assignments for the Node Template that provide values for properties defined in its declared Node Type.
· attribute_assignments: represents the optional map of attribute assignments for the Node Template that provide values for attributes defined in its declared Node Type.
· requirement_assignments: represents the optional list of requirement assignments for the Node Template that allow assignment of type-compatible capabilities, target nodes, relationships and target (node filters) for use when fulfilling the requirement at runtime.
· capability_assignments: represents the optional map of capability assignments for the Node Template that augment those provided by its declared Node Type.
· interface_definitions: represents the optional map of interface definitions for the Node Template that augment those provided by its declared Node Type.
· artifact_definitions: represents the optional map of artifact definitions for the Node Template that augment those provided by its declared Node Type.
· node_filter_definition: represents the optional node filter TOSCA orchestrators would use for selecting a matching node template.
· source_node_template_name: represents the optional (symbolic) name of another node template to copy into (all keynames and values) and use as a basis for this node template.
· The source node template provided as a value on the copy keyname MUST NOT itself use the copy keyname (i.e., it must itself be a complete node template description and not copied from another node template).
|
node_templates: mysql: type: tosca.nodes.DBMS.MySQL properties: root_password: { get_input: my_mysql_rootpw } port: { get_input: my_mysql_port } requirements: - host: db_server interfaces: Standard: configure: scripts/my_own_configure.sh |
A Relationship Template specifies the occurrence of a manageable relationship between node templates as part of an application’s topology model that is defined in a TOSCA Service Template. A Relationship template is an instance of a specified Relationship Type and can provide customized properties, constraints or operations which override the defaults provided by its Relationship Type and its implementations.
The following is the list of recognized keynames for a TOSCA Relationship Template definition:
|
Keyname |
Required |
Type |
Description |
|
type |
yes |
The required name of the Relationship Type the Relationship Template is based upon. |
|
|
description |
no |
An optional description for the Relationship Template. |
|
|
metadata |
no |
Defines a section used to declare additional metadata information. |
|
|
properties |
no |
map of |
An optional map of property assignments for the Relationship Template. |
|
attributes |
no |
map of |
An optional map of attribute assignments for the Relationship Template. |
|
interfaces |
no |
map of |
An optional map of named interface definitions for the Node Template. |
|
copy |
no |
The optional (symbolic) name of another relationship template to copy into (all keynames and values) and use as a basis for this relationship template. |
|
<relationship_template_name>: type: <relationship_type_name> description: <relationship_type_description> metadata: properties: attributes: interfaces: copy: |
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
· relationship_template_name: represents the required symbolic name of the Relationship Template being declared.
· relationship_type_name: represents the name of the Relationship Type the Relationship Template is based upon.
· relationship_template_description: represents the optional description string for the Relationship Template.
· property_assignments: represents the optional map of property assignments for the Relationship Template that provide values for properties defined in its declared Relationship Type.
· attribute_assignments: represents the optional map of attribute assignments for the Relationship Template that provide values for attributes defined in its declared Relationship Type.
· interface_definitions: represents the optional map of interface definitions for the Relationship Template that augment those provided by its declared Relationship Type.
· source_relationship_template_name: represents the optional (symbolic) name of another relationship template to copy into (all keynames and values) and use as a basis for this relationship template.
· The source relationship template provided as a value on the copy keyname MUST NOT itself use the copy keyname (i.e., it must itself be a complete relationship template description and not copied from another relationship template).
|
relationship_templates: storage_attachment: type: AttachesTo properties: location: /my_mount_point |
A group definition defines a logical grouping of node templates, typically for management purposes, but is separate from the application’s topology template.
The following is the list of recognized keynames for a TOSCA group definition:
|
Keyname |
Required |
Type |
Description |
|
type |
yes |
The required name of the group type the group definition is based upon. |
|
|
description |
no |
The optional description for the group definition. |
|
|
metadata |
no |
Defines a section used to declare additional metadata information. |
|
|
properties |
no |
map of |
An optional map of property value assignments for the group definition. |
|
members |
no |
list of string |
The optional list of one or more node template names that are members of this group definition. |
Group definitions have one the following grammars:
|
<group_name>: type: <group_type_name> description: <group_description> metadata: attributes : properties: members: [ <list_of_node_templates> ] |
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
· group_name: represents the required symbolic name of the group as a string.
· group_type_name: represents the name of the Group Type the definition is based upon.
· group_description: contains an optional description of the group.
· attribute_assigments: represents the optional map of attribute_assignments for the group definition that provide values for attributes defined in its declared Group Type.
· property_assignments: represents the optional map of property assignments for the group definition that provide values for properties defined in its declared Group Type.
· list_of_node_templates: contains the required list of one or more node template names (within the same topology template) that are members of this logical group.
Note that earlier versions of this specification support interface definitions in group definitions. These definitions have been deprecated in this version based on the realization that groups in TOSCA only exist for purposes of uniform application of policies to collections of nodes. Consequently, groups do not have a lifecycle of their own that is independent of the lifeycle of their members.
· Group definitions SHOULD NOT be used to define or redefine relationships (dependencies) for an application that can be expressed using normative TOSCA Relationships within a TOSCA topology template.
The following represents a group definition:
|
groups: my_app_placement_group: type: tosca.groups.Root description: My application’s logical component grouping for placement members: [ my_web_server, my_sql_database ] |
A policy definition defines a policy that can be associated with a TOSCA topology or top-level entity definition (e.g., group definition, node template, etc.).
The following is the list of recognized keynames for a TOSCA policy definition:
|
Keyname |
Required |
Type |
Description |
|
type |
yes |
The required name of the policy type the policy definition is based upon. |
|
|
description |
no |
The optional description for the policy definition. |
|
|
metadata |
no |
Defines a section used to declare additional metadata information. |
|
|
properties |
no |
map of |
An optional map of property value assignments for the policy definition. |
|
targets
|
no |
string[] |
An optional list of valid Node Templates or Groups the Policy can be applied to. |
|
triggers |
no |
map of trigger definitions |
An optional map of trigger definitions to invoke when the policy is applied by an orchestrator against the associated TOSCA entity. |
Policy definitions have one the following grammars:
|
<policy_name>: type: <policy_type_name> description: <policy_description> metadata: properties: targets: [<list_of_policy_targets>] triggers: <trigger_definitions> |
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
· policy_name: represents the required symbolic name of the policy as a string.
· policy_type_name: represents the name of the policy the definition is based upon.
· policy_description: contains an optional description of the policy.
· property_assignments: represents the optional map of property assignments for the policy definition that provide values for properties defined in its declared Policy Type.
· list_of_policy_targets: represents the optional list of names of node templates or groups that the policy is to applied to.
· trigger_definitions: represents the optional map of trigger definitions for the policy.
The following represents a policy definition:
|
policies: - my_compute_placement_policy: type: tosca.policies.placement description: Apply my placement policy to my application’s servers targets: [ my_server_1, my_server_2 ] # remainder of policy definition left off for brevity |
A workflow definition defines an imperative workflow that is associated with a TOSCA topology. A workflow definition can either include the steps that make up the workflow, or it can refer to an artifact that expresses the workflow using an external workflow language.
The following is the list of recognized keynames for a TOSCA workflow definition:
|
Keyname |
Required |
Type |
Description |
|
description |
no |
The optional description for the workflow definition. |
|
|
metadata |
no |
Defines a section used to declare additional metadata information. |
|
|
inputs |
no |
map of |
The optional map of input parameter definitions. |
|
preconditions |
no |
list of precondition definitions |
List of preconditions to be validated before the workflow can be processed. |
|
steps
|
no |
map of step definitions |
An optional map of valid imperative workflow step definitions. |
|
implementation |
no |
The optional definition of an external workflow definition. This keyname is mutually exclusive with the steps keyname above. |
|
|
outputs |
no |
map of attribute mappings |
The optional map of attribute mappings that specify named workflow output values and their mappings onto attributes of a node or relationship defined in the topology |
Imperative workflow definitions have the following grammar:
|
<workflow_name>: description: <workflow_description> metadata: inputs: preconditions: - <workflow_precondition_definition> steps: implementation: <operation_implementation_definitions> outputs: <attribute_mappings>
|
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
· workflow_name:
· workflow_description:
· property_definitions:
· workflow_precondition_definition:
· workflow_steps:
· operation_implementation_definition: represents a full inline definition of an implementation artifact
· attribute_mappings: represents the optional map of of attribute_mappings that consists of named output values returned by operation implementations (i.e. artifacts) and associated mappings that specify the attribute into which this output value must be stored.
A property mapping allows to map the property of a substituted node type an input of the topology template.
The following is the list of recognized keynames for a TOSCA property mapping:
|
Keyname |
Required |
Type |
Description |
|
mapping |
no |
list of strings |
An array with 1 string element that references an input of the topology.. |
|
value |
no |
matching the type of this property |
This deprecated keyname allows to explicitly assigne a value to this property. This field is mutually exclusive with the mapping keyname. |
The single-line grammar of a property_mapping is as follows:
|
<property_name>: <property_value> # This use is deprecated <property_name>: [ <input_name> ] |
The multi-line grammar is as follows :
|
<property_name>: mapping: [ < input_name > ] <property_name>: value: <property_value> # This use is deprecated |
· Single line grammar for a property value assignment is not allowed for properties of type in order to avoid collision with the mapping single line grammar.
· The property_value mapping grammar has been deprecated. The original intent of the property-to-constant-value mapping was not to provide a mapping, but rather to present a matching mechanism to drive selection of the appropriate substituting template when more than one template was available as a substitution for the abstract node. In that case, a topology template was only a valid candidate for substitution if the property value in the abstract node template matched the constant value specified in the property_value mapping for that property. With the introduction of substitution filter syntax to drive matching, there is no longer a need for the property-to-constant-value mapping functionality.
· The previous version of the specification allowed direct mappings from properties of the abstract node template to properties of node templates in the substituting topology template. Support for these mappings has been deprecated since they would have resulted in unpredictable behavior, for the following reason. If the substituting template is a valid TOSCA template, then all the (required) properties of all its node templates must have valid property assignments already defined. If the substitution mappings of the substituting template include direct property-to-property mappings, the the substituting template ends up with two conflicting property assignments: one defined in the substituting template itself, and one defined by the substitution mappings. These conflicting assignments lead to unpredictable behavior.
· When Input mapping it may be referenced by multiple nodes in the topologies with resulting attributes values that may differ later on in the various nodes. In any situation, the attribute reflecting the property of the substituted type will remain a constant value set to the one of the input at deployment time.
An attribute mapping allows to map the attribute of a substituted node type an output of the topology template.
The following is the list of recognized keynames for a TOSCA attribute mapping:
|
Keyname |
Required |
Type |
Description |
|
mapping |
no |
list of strings |
An array with 1 string element that references an output of the topology.. |
The single-line grammar of an attribute_mapping is as follows:
|
<attribute_name>: [ <output_name> ] |
A capability mapping allows to map the capability of one of the node of the topology template to the capability of the node type the service template offers an implementation for.
The following is the list of recognized keynames for a TOSCA capability mapping:
|
Keyname |
Required |
Type |
Description |
|
mapping |
no |
list of strings (with 2 members) |
A list of strings with 2 members, the first one being the name of a node template, the second the name of a capability of the specified node template. |
|
properties |
no |
map of property assignments |
This field is mutually exclusive with the mapping keyname and allows to provide a capability assignment for the template and specify it’s related properties. |
|
attributes |
no |
map of attributes assignments |
This field is mutually exclusive with the mapping keyname and allows to provide a capability assignment for the template and specify it’s related attributes. |
The single-line grammar of a capability_mapping is as follows:
|
<capability_name>: [ <node_template_name>, <node_template_capability_name> ] |
The multi-line grammar is as follows :
|
<capability_name>: mapping: [ <node_template_name>, <node_template_capability_name> ] properties: <property_name>: <property_value> attributes: <attribute_name>: <attribute_value> |
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
· capability_name: represents the name of the capability as it appears in the Node Type definition for the Node Type (name) that is declared as the value for on the substitution_mappings’ “node_type” key.
· node_template_name: represents a valid name of a Node Template definition (within the same topology_template declaration as the substitution_mapping is declared).
· node_template_capability_name: represents a valid name of a capability definition within the <node_template_name> declared in this mapping.
· property_name: represents the name of a property of the capability.
· property_value: represents the value to assign to a property of the capability.
· attribute_name: represents the name a an attribute of the capability.
· attribute_value: represents the value to assign to an attribute of the capability.
· Definition of capability assignment in a capability mapping (through properties and attribute keynames) SHOULD be prohibited for connectivity capabilities as tosca.capabilities.Endpoint.
A requirement mapping allows to map the requirement of one of the node of the topology template to the requirement of the node type the service template offers an implementation for.
The following is the list of recognized keynames for a TOSCA requirement mapping:
|
Keyname |
Required |
Type |
Description |
|
mapping |
no |
list of strings (2 members) |
A list of strings with 2 elements, the first one being the name of a node template, the second the name of a requirement of the specified node template. |
|
properties |
no |
List of property assignment |
This field is mutually exclusive with the mapping keyname and allow to provide a requirement for the template and specify it’s related properties. |
|
attributes |
no |
List of attributes assignment |
This field is mutually exclusive with the mapping keyname and allow to provide a requirement for the template and specify it’s related attributes. |
The single-line grammar of a requirement_mapping is as follows:
|
<requirement_name>: [ <node_template_name>, <node_template_requirement_name> ] |
The multi-line grammar is as follows :
|
<requirement_name>: mapping: [ <node_template_name>, <node_template_requirement_name> ] properties: <property_name>: <property_value> attributes: <attribute_name>: <attribute_value> |
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
· requirement_name: represents the name of the requirement as it appears in the Node Type definition for the Node Type (name) that is declared as the value for on the substitution_mappings’ “node_type” key.
· node_template_name: represents a valid name of a Node Template definition (within the same topology_template declaration as the substitution_mapping is declared).
· node_template_requirement_name: represents a valid name of a requirement definition within the <node_template_name> declared in this mapping.
· property_name: represents the name of a property of the requirement.
· property_value: represents the value to assign to a property of the requirement.
· attribute_name: represents the name a an attribute of the requirement.
· attribute_value: represents the value to assign to an attribute of the requirement.
· Definition of capability assignment in a capability mapping (through properties and attribute keynames) SHOULD be prohibited for connectivity capabilities as tosca.capabilities.Endpoint.
An interface mapping allows to map a workflow of the topology template to an operation of the node type the service template offers an implementation for.
The grammar of an interface_mapping is as follows:
|
<interface_name>: <operation_name>: <workflow_name> |
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
· interface_name: represents the name of the interface as it appears in the Node Type definition for the Node Type (name) that is declared as the value for on the substitution_mappings’ “node_type” key. Or the name of a new management interface to add to the generated type.
· operation_name: represents the name of the operation as it appears in the interface type definition.
· workflow_name: represents the name of a workflow of the template to map to the specified operation.
· Declarative workflow generation will be applied by the TOSCA orchestrator after the topology template have been substituted. Unless one of the normative operation of the standard interface is mapped through an interface mapping. In that case the declarative workflow generation will consider the substitution node as any other node calling the create, configure and start mapped workflows as if they where single operations.
· Operation implementation being TOSCA workflows the TOSCA orchestrator replace the usual operation_call activity by an inline activity using the specified workflow.
A substitution mapping allows a given topology template to be used as an implementation of abstract node templates of a specific node type. This allows the consumption of complex systems using a simplified vision.
|
Keyname |
Required |
Type |
Description |
|
node_type |
yes |
string |
The required name of the Node Type the Topology Template is providing an implementation for. |
|
substitution_filter |
no |
The optional filter that further constrains the abstract node templates for which this topology template can provide an implementation. |
|
|
properties |
no |
map of property mappings |
The optional map of properties mapping allowing to map properties of the node_type to inputs of the topology template. |
|
attributes |
no |
map of attribute mappings |
The optional map of attribute mappings allowing to map outputs from the topology template to attributes of the node_type. |
|
capabilities |
no |
map of capability mappings |
The optional map of capabilities mapping. |
|
requirements |
no |
map of requirement mappings |
The optional map of requirements mapping. |
|
interfaces |
no |
map of interfaces mappings |
The optional map of interface mapping allows to map an interface and operations of the node type to implementations that could be either workflows or node template interfaces/operations. |
The grammar of the substitution_mapping section is as follows:
|
node_type: <node_type_name> substitution_filter : <node_filter> properties: <property_mappings> capabilities: <capability_mappings> requirements: <requirement_mappings> attributes: <attribute_mappings> interfaces: <interface_mappings> |
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
· node_type_name: represents the required Node Type name that the Service Template’s topology is offering an implementation for.
· node_filter: represents the optional node filter that reduces the set of abstract node templates for which this topology template is an implementation by only substituting for those node templates whose properties and capabilities satisfy the constraints specified in the node filter.
· properties: represents the <optional> map of properties mappings.
· capability_mappings: represents the <optional> map of capability mappings.
· requirement_mappings: represents the <optional> map of requirement mappings.
· attributes: represents the <optional> map of attributes mappings.
· interfaces: represents the <optional> map of interfaces mappings.
· The substitution mapping MUST provide mapping for every property, capability and requirement defined in the specified <node_type>
· The node_type specified in the substitution mapping SHOULD be abstract (does not provide implementation for normative operations).
This section defines the topology template of a cloud application. The main ingredients of the topology template are node templates representing components of the application and relationship templates representing links between the components. These elements are defined in the nested node_templates section and the nested relationship_templates sections, respectively. Furthermore, a topology template allows for defining input parameters, output parameters as well as grouping of node templates.
The following is the list of recognized keynames for a TOSCA Topology Template:
|
Keyname |
Required |
Type |
Description |
|
description |
no |
The optional description for the Topology Template. |
|
|
inputs |
no |
map of |
An optional map of input parameters (i.e., as parameter definitions) for the Topology Template. |
|
node_templates |
no |
map of |
An optional map of node template definitions for the Topology Template. |
|
relationship_templates |
no |
map of |
An optional map of relationship templates for the Topology Template. |
|
groups |
no |
map of |
An optional map of Group definitions whose members are node templates defined within this same Topology Template. |
|
policies |
no |
list of |
An optional list of Policy definitions for the Topology Template. |
|
outputs |
no |
map of |
An optional map of output parameters (i.e., as parameter definitions) for the Topology Template. |
|
substitution_mappings |
no |
substitution_mapping |
An optional declaration that exports the topology template as an implementation of a Node type.
This also includes the mappings between the external Node Types named capabilities and requirements to existing implementations of those capabilities and requirements on Node templates declared within the topology template. |
|
workflows |
no |
map of imperative workflow definitions |
An optional map of imperative workflow definition for the Topology Template. |
The overall grammar of the topology_template section is shown below.–Detailed grammar definitions of the each sub-sections are provided in subsequent subsections.
|
topology_template: description: <template_description> inputs: <input_parameters> outputs: <output_parameters> node_templates: <node_templates> relationship_templates: <relationship_templates> groups: <group_definitions> policies: - <policy_definition_list> workflows: <workflows> # Optional declaration that exports the Topology Template # as an implementation of a Node Type. substitution_mappings: |
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
· template_description: represents the optional description string for Topology Template.
· input_parameters: represents the optional map of input parameters (i.e., as property definitions) for the Topology Template.
· output_parameters: represents the optional map of output parameters (i.e., as property definitions) for the Topology Template.
· group_definitions: represents the optional map of group definitions whose members are node templates that also are defined within this Topology Template.
· policy_definition_list: represents the optional list of sequenced policy definitions for the Topology Template.
· workflows: represents the optional map of imperative workflow definitions for the Topology Template.
· node_templates: represents the optional map of node template definitions for the Topology Template.
· relationship_templates: represents the optional map of relationship templates for the Topology Template.
· node_type_name: represents the optional name of a Node Type that the Topology Template implements as part of the substitution_mappings.
· map_of_capability_mappings_to_expose: represents the mappings that expose internal capabilities from node templates (within the topology template) as capabilities of the Node Type definition that is declared as part of the substitution_mappings.
· map_of_requirement_mappings_to_expose: represents the mappings of link requirements of the Node Type definition that is declared as part of the substitution_mappings to internal requirements implementations within node templates (declared within the topology template).
More detailed explanations for each of the Topology Template grammar’s keynames appears in the sections below.
The inputs section provides a means to define parameters using TOSCA parameter definitions, their allowed values via constraints and default values within a TOSCA Simple Profile template. Input parameters defined in the inputs section of a topology template can be mapped to properties of node templates or relationship templates within the same topology template and can thus be used for parameterizing the instantiation of the topology template.
This section defines topology template-level input parameter section.
· Inputs here would ideally be mapped to BoundaryDefinitions in TOSCA v1.0.
· Treat input parameters as fixed global variables (not settable within template)
· If not in input take default (nodes use default)
The grammar of the inputs section is as follows:
|
inputs: |
This section provides a set of examples for the single elements of a topology template.
Simple inputs example without any constraints:
|
inputs: fooName: type: string description: Simple string typed property definition with no constraints. default: bar |
Example of inputs with constraints:
|
inputs: SiteName: type: string description: string typed property definition with constraints default: My Site constraints: - min_length: 9 |
The node_templates section lists the Node Templates that describe the (software) components that are used to compose cloud applications.
The grammar of the node_templates section is a follows:
|
node_templates: ... |
Example of node_templates section:
|
node_templates: my_webapp_node_template: type: WebApplication
my_database_node_template: type: Database |
The relationship_templates section lists the Relationship Templates that describe the relations between components that are used to compose cloud applications.
Note that in the TOSCA Simple Profile, the explicit definition of relationship templates as it was required in TOSCA v1.0 is optional, since relationships between nodes get implicitly defined by referencing other node templates in the requirements sections of node templates.
The grammar of the relationship_templates section is as follows:
|
relationship_templates: <relationship_template_defn_1> ... |
Example of relationship_templates section:
|
relationship_templates: my_connectsto_relationship: type: tosca.relationships.ConnectsTo interfaces: Configure: inputs: speed: { get_attribute: [ SOURCE, connect_speed ] } |
The outputs section provides a means to define the output parameters that are available from a TOSCA Simple Profile service template. It allows for exposing attributes of node templates or relationship templates within the containing topology_template to users of a service.
The grammar of the outputs section is as follows:
|
outputs: |
Example of the outputs section:
|
outputs: server_address: description: The first private IP address for the provisioned server. value: { get_attribute: [ HOST, networks, private, addresses, 0 ] } |
The groups section allows for grouping one or more node templates within a TOSCA Service Template and for assigning special attributes like policies to the group.
The grammar of the groups section is as follows:
|
groups: ... |
The following example shows the definition of three Compute nodes in the node_templates section of a topology_template as well as the grouping of two of the Compute nodes in a group server_group_1.
|
node_templates: server1: type: tosca.nodes.Compute # more details ...
server2: type: tosca.nodes.Compute # more details ...
server3: type: tosca.nodes.Compute # more details ...
groups: # server2 and server3 are part of the same group server_group_1: type: tosca.groups.Root members: [ server2, server3 ] |
The policies section allows for declaring policies that can be applied to entities in the topology template.
The grammar of the policies section is as follows:
|
policies: - <policy_defn_1> - ... - <policy_defn_n> |
The following example shows the definition of a placement policy.
|
policies: - my_placement_policy: type: mycompany.mytypes.policy.placement |
The grammar of a requirement_mapping is as follows:
|
<requirement_name>: [ <node_template_name>, <node_template_requirement_name> ] |
The multi-line grammar is as follows :
|
<requirement_name>: mapping: [ <node_template_name>, <node_template_capability_name> ] properties: <property_name>: <property_value> |
· requirement_name: represents the name of the requirement as it appears in the Node Type definition for the Node Type (name) that is declared as the value for on the substitution_mappings’ “node_type” key.
· node_template_name: represents a valid name of a Node Template definition (within the same topology_template declaration as the substitution_mapping is declared).
· node_template_requirement_name: represents a valid name of a requirement definition within the <node_template_name> declared in this mapping.
The following example shows the definition of a placement policy.
|
topology_template:
inputs: cpus: type: integer constraints: less_than: 2 # OR use “defaults” key
substitution_mappings: node_type: MyService properties: # Do not care if running or matching (e.g., Compute node) # get from outside? Get from contsraint? num_cpus: cpus # Implied “PUSH” # get from some node in the topology… num_cpus: [ <node>, <cap>, <property> ] # 1) Running architecture: # a) Explicit value: { get_property: [some_service, architecture] } # b) implicit value: [ some_service, <req | cap name>, <property name> architecture ] default: “amd” # c) INPUT mapping? ??? # 2) Catalog (Matching) architecture: contraints: equals: “x86”
capabilities: bar: [ some_service, bar ] requirements: foo: [ some_service, foo ]
node_templates: some_service: type: MyService properties: rate: 100 capabilities: bar: ... requirements: - foo: ...
|
· The parameters (properties) that are part of the inputs block can be mapped to PropertyMappings provided as part of BoundaryDefinitions as described by the TOSCA v1.0 specification.
· The node templates that are part of the node_templates block can be mapped to the NodeTemplate definitions provided as part of TopologyTemplate of a ServiceTemplate as described by the TOSCA v1.0 specification.
· The relationship templates that are part of the relationship_templates block can be mapped to the RelationshipTemplate definitions provided as part of TopologyTemplate of a ServiceTemplate as described by the TOSCA v1.0 specification.
· The output parameters that are part of the outputs section of a topology template can be mapped to PropertyMappings provided as part of BoundaryDefinitions as described by the TOSCA v1.0 specification.
o Note, however, that TOSCA v1.0 does not define a direction (input vs. output) for those mappings, i.e. TOSCA v1.0 PropertyMappings are underspecified in that respect and TOSCA Simple Profile’s inputs and outputs provide a more concrete definition of input and output parameters.
A TOSCA Service Template (YAML) document contains element definitions of building blocks for cloud application, or complete models of cloud applications. This section describes the top-level structural elements (TOSCA keynames) along with their grammars, which are allowed to appear in a TOSCA Service Template document.
The following is the list of recognized keynames for a TOSCA Service Template definition:
|
Keyname |
Required |
Type |
Description |
|
tosca_definitions_version |
yes |
Defines the version of the TOSCA Simple Profile specification the template (grammar) complies with. |
|
|
namespace |
no |
URI |
The default (target) namespace for all unqualified Types defined within the Service Template.
|
|
metadata |
no |
Defines a section used to declare additional metadata information. Domain-specific TOSCA profile specifications may define keynames that are required for their implementations. |
|
|
description |
no |
Declares a description for this Service Template and its contents. |
|
|
dsl_definitions |
no |
N/A |
Declares optional DSL-specific definitions and conventions. For example, in YAML, this allows defining reusable YAML macros (i.e., YAML alias anchors) for use throughout the TOSCA Service Template. |
|
repositories |
no |
map of |
Declares the map of external repositories which contain artifacts that are referenced in the service template along with their addresses and necessary credential information used to connect to them in order to retrieve the artifacts. |
|
imports |
no |
list of |
Declares a list import statements pointing to external TOSCA Definitions documents. For example, these may be file location or URIs relative to the service template file within the same TOSCA CSAR file. |
|
artifact_types |
no |
map of |
This section contains an optional map of artifact type definitions for use in the service template |
|
data_types |
no |
map of |
Declares a map of optional TOSCA Data Type definitions. |
|
capability_types |
no |
map of |
This section contains an optional map of capability type definitions for use in the service template. |
|
interface_types |
no |
map of |
This section contains an optional map of interface type definitions for use in the service template. |
|
relationship_types |
no |
map of |
This section contains a map of relationship type definitions for use in the service template. |
|
node_types |
no |
map of |
This section contains a map of node type definitions for use in the service template. |
|
group_types |
no |
map of |
This section contains a map of group type definitions for use in the service template. |
|
policy_types |
no |
list of |
This section contains a list of policy type definitions for use in the service template. |
|
no |
Topology Template definition |
Defines the topology template of an application or service, consisting of node templates that represent the application’s or service’s components, as well as relationship templates representing relations between the components. |
The following is the list of recognized metadata keynames for a TOSCA Service Template definition:
|
Keyname |
Required |
Type |
Description |
|
template_name |
no |
Declares a descriptive name for the template. |
|
|
template_author |
no |
Declares the author(s) or owner of the template. |
|
|
template_version |
no |
Declares the version string for the template. |
The overall structure of a TOSCA Service Template and its top-level key collations using the TOSCA Simple Profile is shown below:
|
# Required TOSCA Definitions version string tosca_definitions_version: <value> # Required, see section 3.1 for usage namespace: <URI> # Optional, see section 3.2 for usage
# Optional metadata keyname: value pairs metadata: template_name: <value> # Optional, name of this service template template_author: <value> # Optional, author of this service template template_version: <value> # Optional, version of this service template # More optional entries of domain or profile specific metadata keynames
# Optional description of the definitions inside the file. description: <template_type_description>
dsl_definitions: # map of YAML alias anchors (or macros)
repositories: # map of external repository definitions which host TOSCA artifacts
imports: # ordered list of import definitions
artifact_types: # map of artifact type definitions
data_types: # map of datatype definitions
capability_types: # map of capability type definitions
interface_types # map of interface type definitions
relationship_types: # map of relationship type definitions
node_types: # map of node type definitions
group_types: # map of group type definitions
policy_types: # map of policy type definitions
topology_template: # topology template definition of the cloud application or service |
· The URI value “http://docs.oasis-open.org/tosca”, as well as all (path) extensions to it, SHALL be reserved for TOSCA approved specifications and work. That means Service Templates that do not originate from a TOSCA approved work product MUST NOT use it, in any form, when declaring a (default) Namespace.
· The key “tosca_definitions_version” SHOULD be the first line of each Service Template.
· TOSCA Service Templates do not have to contain a topology_template and MAY contain simply type definitions (e.g., Artifact, Interface, Capability, Node, Relationship Types, etc.) and be imported for use as type definitions in other TOSCA Service Templates.
This required element provides a means to include a reference to the TOSCA Simple Profile specification within the TOSCA Definitions YAML file. It is an indicator for the version of the TOSCA grammar that should be used to parse the remainder of the document.
|
tosca_definitions_version |
Single-line form:
|
tosca_definitions_version: <tosca_simple_profile_version> |
TOSCA Simple Profile version 1.3 specification using the defined namespace alias (see Section 3.1):
|
tosca_definitions_version: tosca_simple_yaml_1_3 |
TOSCA Simple Profile version 1.3 specification using the fully defined (target) namespace (see Section 3.1):
|
tosca_definitions_version: http://docs.oasis-open.org/tosca/ns/simple/yaml/1.3 |
This keyname is used to associate domain-specific metadata with the Service Template. The metadata keyname allows a declaration of a map of keynames with string values.
|
metadata |
|
metadata: <map_of_string_values> |
|
metadata: creation_date: 2015-04-14 date_updated: 2015-05-01 status: developmental |
This optional metadata keyname can be used to declare the name of service template as a single-line string value.
|
template_name |
|
template_name: <name string> |
|
template_name: My service template |
· Some service templates are designed to be referenced and reused by other service templates. Therefore, in these cases, the template_name value SHOULD be designed to be used as a unique identifier through the use of namespacing techniques.
This optional metadata keyname can be used to declare the author(s) of the service template as a single-line string value.
|
template_author |
|
template_author: <author string> |
|
template_author: My service template |
This optional metadata keyname can be used to declare a domain specific version of the service template as a single-line string value.
|
template_version |
|
template_version: <version> |
|
template_version: 2.0.17 |
· Some service templates are designed to be referenced and reused by other service templates and have a lifecycle of their own. Therefore, in these cases, a template_version value SHOULD be included and used in conjunction with a unique template_name value to enable lifecycle management of the service template and its contents.
This optional keyname provides a means to include single or multiline descriptions within a TOSCA Simple Profile template as a scalar string value.
|
description |
This optional keyname provides a section to define macros (e.g., YAML-style macros when using the TOSCA Simple Profile in YAML specification).
|
dsl_definitions |
|
dsl_definitions: ... |
|
dsl_definitions: ubuntu_image_props: &ubuntu_image_props architecture: x86_64 type: linux distribution: ubuntu os_version: 14.04
redhat_image_props: &redhat_image_props architecture: x86_64 type: linux distribution: rhel os_version: 6.6 |
This optional keyname provides a section to define external repositories which may contain artifacts or other TOSCA Service Templates which might be referenced or imported by the TOSCA Service Template definition.
|
repositories |
|
repositories: ... |
|
repositories: my_project_artifact_repo: description: development repository for TAR archives and Bash scripts url: http://mycompany.com/repository/myproject/ |
This optional keyname provides a way to import a block sequence of one or more TOSCA Definitions documents. TOSCA Definitions documents can contain reusable TOSCA type definitions (e.g., Node Types, Relationship Types, Artifact Types, etc.) defined by other authors. This mechanism provides an effective way for companies and organizations to define normative types and/or describe their software applications for reuse in other TOSCA Service Templates.
|
imports |
|
imports: - ... |
|
# An example import of definitions files from a location relative to the # file location of the service template declaring the import. imports: - some_definitions: relative_path/my_defns/my_typesdefs_1.yaml - file: my_defns/my_typesdefs_n.yaml repository: my_company_repo namespace_prefix: mycompany |
This optional keyname lists the Artifact Types that are defined by this Service Template.
|
artifact_types |
|
artifact_types: ... |
|
artifact_types: mycompany.artifacttypes.myFileType: derived_from: tosca.artifacts.File |
This optional keyname provides a section to define new data types in TOSCA.
|
data_types |
|
data_types: ... |
|
data_types: # A complex datatype definition simple_contactinfo_type: properties: name: type: string email: type: string phone: type: string
# datatype definition derived from an existing type full_contact_info: derived_from: simple_contact_info properties: street_address: type: string city: type: string state: type: string postalcode: type: string |
This optional keyname lists the Capability Types that provide the reusable type definitions that can be used to describe features Node Templates or Node Types can declare they support.
|
capability_types |
|
capability_types: ... |
|
capability_types: mycompany.mytypes.myCustomEndpoint: derived_from: tosca.capabilities.Endpoint properties: # more details ...
mycompany.mytypes.myCustomFeature: derived_from: tosca.capabilities.Feature properties: # more details ... |
This optional keyname lists the Interface Types that provide the reusable type definitions that can be used to describe operations for on TOSCA entities such as Relationship Types and Node Types.
|
interface_types |
|
interface_types: ... |
|
interface_types: mycompany.interfaces.service.Signal: signal_begin_receive: description: Operation to signal start of some message processing. signal_end_receive: description: Operation to signal end of some message processed. |
This optional keyname lists the Relationship Types that provide the reusable type definitions that can be used to describe dependent relationships between Node Templates or Node Types.
|
relationship_types |
|
relationship_types: ... |
|
relationship_types: mycompany.mytypes.myCustomClientServerType: derived_from: tosca.relationships.HostedOn properties: #
more details ... mycompany.mytypes.myCustomConnectionType: derived_from: tosca.relationships.ConnectsTo properties: # more details ... |
This optional keyname lists the Node Types that provide the reusable type definitions for software components that Node Templates can be based upon.
|
node_types |
|
node_types: ... |
|
node_types: my_webapp_node_type: derived_from: WebApplication properties: my_port: type: integer
my_database_node_type: derived_from: Database capabilities: mytypes.myfeatures.transactSQL |
· The node types that are part of the node_types block can be mapped to the NodeType definitions as described by the TOSCA v1.0 specification.
This optional keyname lists the Group Types that are defined by this Service Template.
|
group_types |
|
group_types: ... |
|
group_types: mycompany.mytypes.myScalingGroup: derived_from: tosca.groups.Root |
This optional keyname lists the Policy Types that are defined by this Service Template.
|
policy_types |
|
policy_types: ... |
|
policy_types: mycompany.mytypes.myScalingPolicy: derived_from: tosca.policies.Scaling |
Except for the examples, this section is normative and includes functions that are supported for use within a TOSCA Service Template.
The following keywords MAY be used in some TOSCA function in place of a TOSCA Node or Relationship Template name. A TOSCA orchestrator will interpret them at the time the function would be evaluated at runtime as described in the table below. Note that some keywords are only valid in the context of a certain TOSCA entity as also denoted in the table.
|
Keyword |
Valid Contexts |
Description |
|
SELF |
Node Template or Relationship Template |
A TOSCA orchestrator will interpret this keyword as the Node or Relationship Template instance that contains the function at the time the function is evaluated. |
|
SOURCE |
Relationship Template only. |
A TOSCA orchestrator will interpret this keyword as the Node Template instance that is at the source end of the relationship that contains the referencing function. |
|
TARGET |
Relationship Template only. |
A TOSCA orchestrator will interpret this keyword as the Node Template instance that is at the target end of the relationship that contains the referencing function. |
|
HOST |
Node Template only |
A TOSCA orchestrator will interpret this keyword to refer to the all nodes that “host” the node using this reference (i.e., as identified by its HostedOn relationship).
Specifically, TOSCA orchestrators that encounter this keyword when evaluating the get_attribute or get_property functions SHALL search each node along the “HostedOn” relationship chain starting at the immediate node that hosts the node where the function was evaluated (and then that node’s host node, and so forth) until a match is found or the “HostedOn” relationship chain ends. |
TOSCA orchestrators utilize certain reserved keywords in the execution environments that implementation artifacts for Node or Relationship Templates operations are executed in. They are used to provide information to these implementation artifacts such as the results of TOSCA function evaluation or information about the instance model of the TOSCA application
The following keywords are reserved environment variable names in any TOSCA supported execution environment:
|
Keyword |
Valid Contexts |
Description |
|
TARGETS |
Relationship Template only. |
· For an implementation artifact that is executed in the context of a relationship, this keyword, if present, is used to supply a list of Node Template instances in a TOSCA application’s instance model that are currently target of the context relationship. · The value of this environment variable will be a comma-separated list of identifiers of the single target node instances (i.e., the tosca_id attribute of the node). |
|
TARGET |
Relationship Template only. |
· For an implementation artifact that is executed in the context of a relationship, this keyword, if present, identifies a Node Template instance in a TOSCA application’s instance model that is a target of the context relationship, and which is being acted upon in the current operation. · The value of this environment variable will be the identifier of the single target node instance (i.e., the tosca_id attribute of the node). |
|
SOURCES |
Relationship Template only. |
· For an implementation artifact that is executed in the context of a relationship, this keyword, if present, is used to supply a list of Node Template instances in a TOSCA application’s instance model that are currently source of the context relationship. · The value of this environment variable will be a comma-separated list of identifiers of the single source node instances (i.e., the tosca_id attribute of the node). |
|
SOURCE |
Relationship Template only. |
· For an implementation artifact that is executed in the context of a relationship, this keyword, if present, identifies a Node Template instance in a TOSCA application’s instance model that is a source of the context relationship, and which is being acted upon in the current operation. · The value of this environment variable will be the identifier of the single source node instance (i.e., the tosca_id attribute of the node). |
For scripts (or implementation artifacts in general) that run in the context of relationship operations, select properties and attributes of both the relationship itself as well as select properties and attributes of the source and target node(s) of the relationship can be provided to the environment by declaring respective operation inputs.
Declared inputs from mapped properties or attributes of the source or target node (selected via the SOURCE or TARGET keyword) will be provided to the environment as variables having the exact same name as the inputs. In addition, the same values will be provided for the complete set of source or target nodes, however prefixed with the ID if the respective nodes. By means of the SOURCES or TARGETS variables holding the complete set of source or target node IDs, scripts will be able to iterate over corresponding inputs for each provided ID prefix.
The following example snippet shows an imaginary relationship definition from a load-balancer node to worker nodes. A script is defined for the add_target operation of the Configure interface of the relationship, and the ip_address attribute of the target is specified as input to the script:
|
node_templates: load_balancer: type: some.vendor.LoadBalancer requirements: - member: relationship: some.vendor.LoadBalancerToMember interfaces: Configure: add_target: inputs: member_ip: { get_attribute: [ TARGET, ip_address ] } implementation: scripts/configure_members.py |
The add_target operation will be invoked, whenever a new target member is being added to the load-balancer. With the above inputs declaration, a member_ip environment variable that will hold the IP address of the target being added will be provided to the configure_members.py script. In addition, the IP addresses of all current load-balancer members will be provided as environment variables with a naming scheme of <target node ID>_member_ip. This will allow, for example, scripts that always just write the complete list of load-balancer members into a configuration file to do so instead of updating existing list, which might be more complicated.
Assuming that the TOSCA application instance includes five load-balancer members, node1 through node5, where node5 is the current target being added, the following environment variables (plus potentially more variables) would be provided to the script:
|
# the ID of the current target and the IDs of all targets TARGET=node5 TARGETS=node1,node2,node3,node4,node5
# the input for the current target and the inputs of all targets member_ip=<IP_ADDRESS> node1_member_ip=<IP_ADDRESS> node2_member_ip=<IP_ADDRESS> node3_member_ip=<IP_ADDRESS> node4_member_ip=<IP_ADDRESS> node5_member_ip=<IP_ADDRESS> |
With code like shown in the snippet below, scripts could then iterate of all provided member_ip inputs:
|
#!/usr/bin/python import os
targets = os.environ['TARGETS'].split(',')
for t in targets: target_ip = os.environ.get('%s_member_ip' % t) # do something with target_ip ... |
The list target node types assigned to the TARGETS key in an execution environment would have names prefixed by unique IDs that distinguish different instances of a node in a running model Future drafts of this specification will show examples of how these names/IDs will be expressed.
· Target of interest is always un-prefixed. Prefix is the target opaque ID. The IDs can be used to find the environment var. for the corresponding target. Need an example here.
· If you have one node that contains multiple targets this would also be used (add or remove target operations would also use this you would get set of all current targets).
These functions are supported within the TOSCA template for manipulation of template data.
The concat function is used to concatenate two or more string values within a TOSCA service template.
|
concat: [<string_value_expressions_*> ] |
|
Parameter |
Required |
Type |
Description |
|
<string_value_expressions_*> |
yes |
list of string or string value expressions |
A list of one or more strings (or expressions that result in a string value) which can be concatenated together into a single string. |
|
outputs: description: Concatenate the URL for a server from other template values server_url: value: { concat: [ 'http://', get_attribute: [ server, public_address ], ':', get_attribute: [ server, port ] ] } |
The join function is used to join an array of strings into a single string with optional delimiter.
|
join: [<list of string_value_expressions_*> [ <delimiter> ] ] |
|
Parameter |
Required |
Type |
Description |
|
<list of string_value_expressions_*> |
yes |
list of string or string value expressions |
A list of one or more strings (or expressions that result in a list of string values) which can be joined together into a single string. |
|
<delimiter> |
no |
string |
An optional delimiter used to join the string in the provided list. |
|
outputs: example1: # Result: prefix_1111_suffix value: { join: [ ["prefix", 1111, "suffix" ], "_" ] } example2: # Result: <IP_ADDRESS>,<IP_ADDRESS> value: { join: [ { get_input: my_IPs }, “,” ] } |
The token function is used within a TOSCA service template on a string to parse out (tokenize) substrings separated by one or more token characters within a larger string.
|
token: [ <string_with_tokens>, <string_of_token_chars>, <substring_index> ] |
|
Parameter |
Required |
Type |
Description |
|
string_with_tokens |
yes |
The composite string that contains one or more substrings separated by token characters. |
|
|
string_of_token_chars |
yes |
The string that contains one or more token characters that separate substrings within the composite string. |
|
|
substring_index |
yes |
The integer indicates the index of the substring to return from the composite string. Note that the first substring is denoted by using the ‘0’ (zero) integer value. |
|
outputs: webserver_port: description: the port provided at the end of my server’s endpoint’s IP address value: { token: [ get_attribute: [ my_server, data_endpoint, ip_address ], ‘:’, 1 ] } |
These functions are used within a service template to obtain property values from property definitions declared elsewhere in the same service template. These property definitions can appear either directly in the service template itself (e.g., in the inputs section) or on entities (e.g., node or relationship templates) that have been modeled within the template.
Note that the get_input and get_property functions may only retrieve the static values of property definitions of a TOSCA application as defined in the TOSCA Service Template. The get_attribute function should be used to retrieve values for attribute definitions (or property definitions reflected as attribute definitions) from the runtime instance model of the TOSCA application (as realized by the TOSCA orchestrator).
The get_input function is used to retrieve the values of properties declared within the inputs section of a TOSCA Service Template.
|
get_input: <input_property_name> |
or
|
get_input: [ <input_property_name>, <nested_input_property_name_or_index_1>, ..., <nested_input_property_name_or_index_n> ] |
|
Parameter |
Required |
Type |
Description |
|
<input_property_name> |
yes |
The name of the property as defined in the inputs section of the service template. |
|
|
<nested_input_property_name_or_index_*> |
no |
Some TOSCA input properties are complex (i.e., composed as nested structures). These parameters are used to dereference into the names of these nested structures when needed.
Some properties represent list types. In these cases, an index may be provided to reference a specific entry in the list (as named in the previous parameter) to return. |
The following snippet shows an example of the simple get_input grammar:
|
inputs: cpus: type: integer
node_templates: my_server: type: tosca.nodes.Compute capabilities: host: properties: num_cpus: { get_input: cpus } |
The following template shows an example of the nested get_input grammar. The template expects two input values, each of which has a complex data type. The get_input function is used to retrieve individual fields from the complex input data.
|
data_types: NetworkInfo: derived_from: tosca.Data.Root properties: name: type: string gateway: type: string
RouterInfo: derived_from: tosca.Data.Root properties: ip: type: string external: type: string
topology_template: inputs: management_network: type: NetworkInfo router: type: RouterInfo
node_templates: Bono_Main: type: vRouter.Cisco directives: [ substitutable ] properties: mgmt_net_name: { get_input: [management_network, name]} mgmt_cp_v4_fixed_ip: { get_input: [router, ip]} mgmt_cp_gateway_ip: { get_input: [management_network, gateway]} mgmt_cp_external_ip: { get_input: [router, external]} requirements: - lan_port: node: host_with_net capability: virtualBind - mgmt_net: mgmt_net |
The get_property function is used to retrieve property values between modelable entities defined in the same service template.
|
get_property: [ <modelable_entity_name>, <optional_req_or_cap_name>, <property_name>, <nested_property_name_or_index_1>, ..., <nested_property_name_or_index_n> ] |
|
Parameter |
Required |
Type |
Description |
|
<modelable entity name> | SELF | SOURCE | TARGET | HOST |
yes |
The required name of a modelable entity (e.g., Node Template or Relationship Template name) as declared in the service template that contains the named property definition the function will return the value from. See section B.1 for valid keywords. |
|
|
<optional_req_or_cap_name> |
no |
The optional name of the requirement or capability name within the modelable entity (i.e., the <modelable_entity_name> which contains the named property definition the function will return the value from.
Note: If the property definition is located in the modelable entity directly, then this parameter MAY be omitted. |
|
|
<property_name> |
yes |
The name of the property definition the function will return the value from. |
|
|
<nested_property_name_or_index_*> |
no |
Some TOSCA properties are complex (i.e., composed as nested structures). These parameters are used to dereference into the names of these nested structures when needed.
Some properties represent list types. In these cases, an index may be provided to reference a specific entry in the list (as named in the previous parameter) to return. |
The following example shows how to use the get_property function with an actual Node Template name:
|
node_templates:
mysql_database: type: tosca.nodes.Database properties: name: sql_database1
wordpress: type: tosca.nodes.WebApplication.WordPress ... interfaces: Standard: configure: inputs: wp_db_name: { get_property: [ mysql_database, name ] } |
The following example shows how to use the get_property function using the SELF keyword:
|
node_templates:
mysql_database: type: tosca.nodes.Database ... capabilities: database_endpoint: properties: port: 3306
wordpress: type: tosca.nodes.WebApplication.WordPress requirements: ... - database_endpoint: mysql_database interfaces: Standard: create: wordpress_install.sh configure: implementation: wordpress_configure.sh inputs: ... wp_db_port: { get_property: [ SELF, database_endpoint, port ] } |
The following example shows how to use the get_property function using the TARGET keyword:
|
relationship_templates: my_connection: type: ConnectsTo interfaces: Configure: inputs: targets_value: { get_property: [ TARGET, value ] } |
These functions (attribute functions) are used within an instance model to obtain attribute values from instances of nodes and relationships that have been created from an application model described in a service template. The instances of nodes or relationships can be referenced by their name as assigned in the service template or relative to the context where they are being invoked.
The get_attribute function is used to retrieve the values of named attributes declared by the referenced node or relationship template name.
|
get_attribute: [ <modelable_entity_name>, <optional_req_or_cap_name>, <attribute_name>, <nested_attribute_name_or_index_1>, ..., <nested_attribute_name_or_index_n> ] |
|
Parameter |
Required |
Type |
Description |
|
<modelable entity name> | SELF | SOURCE | TARGET | HOST |
yes |
The required name of a modelable entity (e.g., Node Template or Relationship Template name) as declared in the service template that contains the named attribute definition the function will return the value from. See section B.1 for valid keywords. |
|
|
<optional_req_or_cap_name> |
no |
The optional name of the requirement or capability name within the modelable entity (i.e., the <modelable_entity_name> which contains the named attribute definition the function will return the value from.
Note: If the attribute definition is located in the modelable entity directly, then this parameter MAY be omitted. |
|
|
<attribute_name> |
yes |
The name of the attribute definition the function will return the value from. |
|
|
<nested_attribute_name_or_index_*> |
no |
Some TOSCA attributes are complex (i.e., composed as nested structures). These parameters are used to dereference into the names of these nested structures when needed.
Some attributes represent list types. In these cases, an index may be provided to reference a specific entry in the list (as named in the previous parameter) to return. |
The attribute functions are used in the same way as the equivalent Property functions described above. Please see their examples and replace “get_property” with “get_attribute” function name.
These functions are used to obtain attributes from instances of node or relationship templates by the names they were given within the service template that described the application model (pattern).
These functions are used within an instance model to obtain values from interface operations. These can be used in order to set an attribute of a node instance at runtime or to pass values from one operation to another.
The get_operation_output function is used to retrieve the values of variables exposed / exported from an interface operation.
|
get_operation_output: <modelable_entity_name>, <interface_name>, <operation_name>, <output_variable_name> |
|
Parameter |
Required |
Type |
Description |
|
<modelable entity name> | SELF | SOURCE | TARGET |
yes |
The required name of a modelable entity (e.g., Node Template or Relationship Template name) as declared in the service template that implements the named interface and operation. |
|
|
<interface_name> |
Yes |
The required name of the interface which defines the operation. |
|
|
<operation_name> |
yes |
The required name of the operation whose value we would like to retrieve. |
|
|
<output_variable_name> |
Yes |
The required name of the variable that is exposed / exported by the operation.
|
· If operation failed, then ignore its outputs. Orchestrators should allow orchestrators to continue running when possible past deployment in the lifecycle. For example, if an update fails, the application should be allowed to continue running and some other method would be used to alert administrators of the failure.
· This version of the TOSCA Simple Profile does not define any model navigation functions.
The get_nodes_of_type function can be used to retrieve a list of all known instances of nodes of the declared Node Type.
|
get_nodes_of_type: <node_type_name> |
|
Parameter |
Required |
Type |
Description |
|
<node_type_name> |
yes |
The required name of a Node Type that a TOSCA orchestrator would use to search a running application instance in order to return all unique, named node instances of that type. |
|
Return Key |
Type |
Description |
|
TARGETS |
<see above> |
The list of node instances from the current application instance that match the node_type_name supplied as an input parameter of this function. |
The get_artifact function is used to retrieve artifact location between modelable entities defined in the same service template.
|
get_artifact: [ <modelable_entity_name>, <artifact_name>, <location>, <remove> ] |
|
Parameter |
Required |
Type |
Description |
|
<modelable entity name> | SELF | SOURCE | TARGET | HOST |
yes |
The required name of a modelable entity (e.g., Node Template or Relationship Template name) as declared in the service template that contains the named property definition the function will return the value from. See section B.1 for valid keywords. |
|
|
<artifact_name> |
yes |
The name of the artifact definition the function will return the value from. |
|
|
<location> | LOCAL_FILE |
no |
Location value must be either a valid path e.g. ‘/etc/var/my_file’ or ‘LOCAL_FILE’.
If the value is LOCAL_FILE the orchestrator is responsible for providing a path as the result of the get_artifact call where the artifact file can be accessed. The orchestrator will also remove the artifact from this location at the end of the operation.
If the location is a path specified by the user the orchestrator is responsible to copy the artifact to the specified location. The orchestrator will return the path as the value of the get_artifact function and leave the file here after the execution of the operation. |
|
|
remove |
no |
Boolean flag to override the orchestrator default behavior so it will remove or not the artifact at the end of the operation execution.
If not specified the removal will depends of the location e.g. removes it in case of ‘LOCAL_FILE’ and keeps it in case of a path.
If true the artifact will be removed by the orchestrator at the end of the operation execution, if false it will not be removed. |
The following example uses a snippet of a WordPress [WordPress] web application to show how to use the get_artifact function with an actual Node Template name:
|
node_templates:
wordpress: type: tosca.nodes.WebApplication.WordPress ... interfaces: Standard: configure: create: implementation: wordpress_install.sh inputs wp_zip: { get_artifact: [ SELF, zip ] } artifacts: zip: /data/wordpress.zip |
In such implementation the TOSCA orchestrator may provide the wordpress.zip archive as
· a local URL (example: file://home/user/wordpress.zip) or
· a remote one (example: http://cloudrepo:80/files/wordpress.zip) where some orchestrator may indeed provide some global artifact repository management features.
The following example explains how to force the orchestrator to copy the file locally before calling the operation’s implementation script:
|
node_templates:
wordpress: type: tosca.nodes.WebApplication.WordPress ... interfaces: Standard: configure: create: implementation: wordpress_install.sh inputs wp_zip: { get_artifact: [ SELF, zip, LOCAL_FILE] } artifacts: zip: /data/wordpress.zip |
In such implementation the TOSCA orchestrator must provide the wordpress.zip archive as a local path (example: /tmp/wordpress.zip) and will remove it after the operation is completed.
The following example explains how to force the orchestrator to copy the file locally to a specific location before calling the operation’s implementation script :
|
node_templates:
wordpress: type: tosca.nodes.WebApplication.WordPress ... interfaces: Standard: configure: create: implementation: wordpress_install.sh inputs wp_zip: { get_artifact: [ SELF, zip, C:/wpdata/wp.zip ] } artifacts: zip: /data/wordpress.zip |
In such implementation the TOSCA orchestrator must provide the wordpress.zip archive as a local path (example: C:/wpdata/wp.zip ) and will let it after the operation is completed.
Future versions of this specification will address methods to access entity names based upon the context in which they are declared or defined.
· Using the full paths of modelable entity names to qualify context with the future goal of a more robust get_attribute function: e.g., get_attribute( <context-based-entity-name>, <attribute name>)
Except for the examples, this section is normative and contains normative type definitions which must be supported for conformance to this specification.
The declarative approach is heavily dependent of the definition of basic types that a declarative container must understand. The definition of these types must be very clear such that the operational semantics can be precisely followed by a declarative container to achieve the effects intended by the modeler of a topology in an interoperable manner.
· Assumes alignment with/dependence on XML normative types proposal for TOSCA v1.1
· Assumes that the normative types will be versioned and the TOSCA TC will preserve backwards compatibility.
· Assumes that security and access control will be addressed in future revisions or versions of this specification.
Every normative type has three names declared:
1. Type URI – This is the unique identifying name for the type.
a. These are reserved names within the TOSCA namespace.
2. Shorthand Name – This is the shorter (simpler) name that can be used in place of its corresponding, full Type URI name.
a. These are reserved names within TOSCA namespace that MAY be used in place of the full Type URI.
b. Profiles of the OASIS TOSCA Simple Profile specifcaition SHALL assure non-collision of names for new types when they are introduced.
c. TOSCA type designers SHOULD NOT create new types with names that would collide with any TOSCA normative type Shorthand Name.
3. Type Qualified Name – This is a modified Shorthand Name that includes the “tosca:” namespace prefix which clearly qualifies it as being part of the TOSCA namespace.
a. This name MAY be used to assure there is no collision when types are imported from other (non) TOSCA approved sources.
· Case sensitivity - TOSCA Type URI, Shorthand and Type Qualified names SHALL be treated as case sensitive.
o The case of each type name has been carefully selected by the TOSCA working group and TOSCA orchestrators and processors SHALL strictly recognize the name casing as specified in this specification or any of its approved profiles.
This is the default (root) TOSCA Root Type definition that all complex TOSCA Data Types derive from.
The TOSCA Root type is defined as follows:
|
tosca.datatypes.Root: description: The TOSCA root Data Type all other TOSCA base Data Types derive from |
The json type is a TOSCA data Type used to define a string that containst data in the JavaScript Object Notation (JSON) format.
|
Shorthand Name |
json |
|
Type Qualified Name |
tosca:json |
|
Type URI |
tosca.datatypes.json |
The json type is defined as follows:
|
tosca.datatypes.json: |
Simple declaration of an ‘event_object’ property declared to be a ‘json’ data type with its associated JSON Schema:
|
properties: event_object: type: json constraints: schema: > { "$schema": "http://json-schema.org/draft-04/schema#", "title": "Event", "description": "Example Event type schema", "type": "object", "properties": { "uuid": { "description": "The unique ID for the event.", "type": "string" }, "code": { "type": "integer" }, "message": { "type": "string" } }, "required": ["uuid", "code"] } |
This example shows a valid JSON datatype value for the ‘event_object’ schema declare in the previous example.
|
# properties snippet from a TOSCA template definition. properties: event_object: < { “uuid”: “cadf:1234-56-0000-abcd”, “code”: 9876 } |
· The json datatype SHOULD only be assigned string values that contain valid JSON syntax as defined by the “The JSON Data Interchange Format Standard” (see reference [JSON-Spec]).
The xml type is a TOSCA data Type used to define a string that containst data in the Extensible Markup Language (XML) format.
|
Shorthand Name |
xml |
|
Type Qualified Name |
tosca:xml |
|
Type URI |
tosca.datatypes.xml |
The xml type is defined as follows:
|
tosca.datatypes.xml: |
Simple declaration of an ‘event_object’ property declared to be an ‘xml’ data type with its associated XML Schema:
|
properties: event_object: type: xml constraints: schema: > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://cloudplatform.org/events.xsd" xmlns="http://tempuri.org/po.xsd" elementFormDefault="qualified"> <xs:annotation> <xs:documentation xml:lang="en"> Event object. </xs:documentation> </xs:annotation> <xs:element name="eventObject"> <xs:complexType> <xs:sequence> <xs:element name="uuid" type="xs:string"/> <xs:element name="code" type="xs:integer"/> <xs:element name="message" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> |
This example shows a valid XML datatype value for the ‘event_object’ schema declare in the previous example.
|
# properties snippet from a TOSCA template definition. properties: event_object: < <eventObject> <uuid>cadf:1234-56-0000-abcd</uuid> <code>9876</code> </eventObject> |
The xml datatype SHOULD only be assigned string values that contain valid XML syntax as defined by the “Extensible Markup Language (XML)” specification” (see reference [XMLSpec]).
The Credential type is a complex TOSCA data Type used when describing authorization credentials used to access network accessible resources.
|
Shorthand Name |
Credential |
|
Type Qualified Name |
tosca:Credential |
|
Type URI |
tosca.datatypes.Credential |
|
Name |
Required |
Type |
Constraints |
Description |
|
protocol |
no |
None |
The optional protocol name. |
|
|
token_type |
yes |
default: password |
The required token type. |
|
|
token |
yes |
None |
The required token used as a credential for authorization or access to a networked resource. |
|
|
keys |
no |
None |
The optional map of protocol-specific keys or assertions. |
|
|
user |
no |
None |
The optional user (name or ID) used for non-token based credentials. |
The TOSCA Credential type is defined as follows:
|
tosca.datatypes.Credential: derived_from: tosca.datatypes.Root properties: protocol: type: string required: false token_type: type: string default: password token: type: string keys: type: map required: false entry_schema: type: string user: type: string required: false |
· TOSCA Orchestrators SHALL interpret and validate the value of the token property based upon the value of the token_type property.
· Specific token types and encoding them using network protocols are not defined or covered in this specification.
· The use of transparent user names (IDs) or passwords are not considered best practice.
|
<some_tosca_entity>: properties: my_credential: type: Credential properties: user: myusername token: mypassword |
|
<some_tosca_entity>: properties: my_credential: # type: Credential protocol: http token_type: basic_auth # Username and password are combined into a string # Note: this would be base64 encoded before transmission by any impl. token: myusername:mypassword |
|
<some_tosca_entity>: properties: my_credential: # type: Credential protocol: xauth token_type: X-Auth-Token # token encoded in Base64 token: 604bbe45ac7143a79e14f3158df67091 |
|
<some_tosca_entity>: properties: my_credential: # type: Credential protocol: oauth2 token_type: bearer # token encoded in Base64 token: 8ao9nE2DEjr1zCsicWMpBC |
|
<some_tosca_entity>: properties: my_ssh_keypair: # type: Credential protocol: ssh token_type: identifier # token is a reference (ID) to an existing keypair (already installed) token: <keypair_id> |
The TimeInterval type is a complex TOSCA data Type used when describing a period of time using the YAML ISO 8601 format to declare the start and end times.
|
Shorthand Name |
TimeInterval |
|
Type Qualified Name |
tosca:TimeInterval |
|
Type URI |
tosca.datatypes.TimeInterval |
|
Name |
Required |
Type |
Constraints |
Description |
|
start_time |
yes |
timestamp |
None |
The inclusive start time for the time interval. |
|
end_time |
yes |
timestamp |
None |
The inclusive end time for the time interval. |
The TOSCA TimeInterval type is defined as follows:
|
tosca.datatypes.TimeInterval: derived_from: tosca.datatypes.Root properties: start_time: type: timestamp required: true end_time: type: timestamp required: true |
|
properties: description: evaluation_period: Evaluate a service for a 5-day period across time zones type: TimeInterval start_time: 2016-04-04-15T00:00:00Z end_time: 2016-04-08T21:59:43.10-06:00 |
The Network type is a complex TOSCA data type used to describe logical network information.
|
Shorthand Name |
NetworkInfo |
|
Type Qualified Name |
tosca:NetworkInfo |
|
Type URI |
tosca.datatypes.network.NetworkInfo |
|
Name |
Type |
Constraints |
Description |
|
network_name |
None |
The name of the logical network. e.g., “public”, “private”, “admin”. etc. |
|
|
network_id |
None |
The unique ID of for the network generated by the network provider. |
|
|
addresses |
string [] |
None |
The list of IP addresses assigned from the underlying network. |
The TOSCA NetworkInfo data type is defined as follows:
|
tosca.datatypes.network.NetworkInfo: derived_from: tosca.datatypes.Root properties: network_name: type: string network_id: type: string addresses: type: list entry_schema: type: string |
Example usage of the NetworkInfo data type:
|
<some_tosca_entity>: properties: private_network: network_name: private network_id: 3e54214f-5c09-1bc9-9999-44100326da1b addresses: [ <IP_ADDRESS> ] |
· It is expected that TOSCA orchestrators MUST be able to map the network_name from the TOSCA model to underlying network model of the provider.
· The properties (or attributes) of NetworkInfo may or may not be required depending on usage context.
The PortInfo type is a complex TOSCA data type used to describe network port information.
|
Shorthand Name |
PortInfo |
|
Type Qualified Name |
tosca:PortInfo |
|
Type URI |
tosca.datatypes.network.PortInfo |
|
Name |
Type |
Constraints |
Description |
|
port_name |
None |
The logical network port name. |
|
|
port_id |
None |
The unique ID for the network port generated by the network provider. |
|
|
network_id |
None |
The unique ID for the network. |
|
|
mac_address |
None |
The unique media access control address (MAC address) assigned to the port. |
|
|
addresses |
string [] |
None |
The list of IP address(es) assigned to the port. |
The TOSCA PortInfo type is defined as follows:
|
tosca.datatypes.network.PortInfo: derived_from: tosca.datatypes.Root properties: port_name: type: string port_id: type: string network_id: type: string mac_address: type: string addresses: type: list entry_schema: type: string |
Example usage of the PortInfo data type:
|
<some_tosca_entity>: properties: ethernet_port: port_name: port1 port_id: 2c0c7a37-691a-23a6-7709-2d10ad041467 network_id: 3e54214f-5c09-1bc9-9999-44100326da1b mac_address: f1:18:3b:41:92:1e addresses: [ <IP_ADDRESS> ] |
· It is expected that TOSCA orchestrators MUST be able to map the port_name from the TOSCA model to underlying network model of the provider.
· The properties (or attributes) of PortInfo may or may not be required depending on usage context.
The PortDef type is a TOSCA data Type used to define a network port.
|
Shorthand Name |
PortDef |
|
Type Qualified Name |
tosca:PortDef |
|
Type URI |
tosca.datatypes.network.PortDef |
The TOSCA PortDef type is defined as follows:
|
tosca.datatypes.network.PortDef: constraints: - in_range: [ 1, 65535 ] |
Simple usage of a PortDef property type:
|
properties: listen_port: 9090 |
Example declaration of a property for a custom type based upon PortDef:
|
properties: listen_port: type: PortDef default: 9000 constraints: - in_range: [ 9000, 9090 ] |
The PortSpec type is a complex TOSCA data Type used when describing port specifications for a network connection.
|
Shorthand Name |
PortSpec |
|
Type Qualified Name |
tosca:PortSpec |
|
Type URI |
tosca.datatypes.network.PortSpec |
|
Name |
Required |
Type |
Constraints |
Description |
|
protocol |
yes |
default: tcp |
The required protocol used on the port. |
|
|
source |
no |
See PortDef |
The optional source port. |
|
|
source_range |
no |
in_range: [ 1, 65536 ] |
The optional range for source port. |
|
|
target |
no |
See PortDef |
The optional target port. |
|
|
target_range |
no |
in_range: [ 1, 65536 ] |
The optional range for target port. |
The TOSCA PortSpec type is defined as follows:
|
tosca.datatypes.network.PortSpec: derived_from: tosca.datatypes.Root properties: protocol: type: string required: true default: tcp constraints: - valid_values: [ udp, tcp, igmp ] target: type: PortDef required: false target_range: type: range required: false constraints: - in_range: [ 1, 65535 ] source: type: PortDef required: false source_range: type: range required: false constraints: - in_range: [ 1, 65535 ] |
· A valid PortSpec MUST have at least one of the following properties: target, target_range, source or source_range.
· A valid PortSpec MUST have a value for the source property that is within the numeric range specified by the property source_range when source_range is specified.
· A valid PortSpec MUST have a value for the target property that is within the numeric range specified by the property target_range when target_range is specified.
Example usage of the PortSpec data type:
|
# example properties in a node template some_endpoint: properties: ports: user_port: protocol: tcp target: 50000 target_range: [ 20000, 60000 ] source: 9000 source_range: [ 1000, 10000 ] |
TOSCA Artifacts Types represent the types of packages and files used by the orchestrator when deploying TOSCA Node or Relationship Types or invoking their interfaces. Currently, artifacts are logically divided into three categories:
· Deployment Types: includes those artifacts that are used during deployment (e.g., referenced on create and install operations) and include packaging files such as RPMs, ZIPs, or TAR files.
· Implementation Types: includes those artifacts that represent imperative logic and are used to implement TOSCA Interface operations. These typically include scripting languages such as Bash (.sh), Chef [Chef] and Puppet [Puppet].
· Runtime Types: includes those artifacts that are used during runtime by a service or component of the application. This could include a library or language runtime that is needed by an application such as a PHP or Java library.
· Template Types: includes those artifacts that are executed by template engines which play the role of artifact processors. Typically, template artifact types are static files. At runtime, the template engine processes the artifact by replacing variables in a template file with actual values. Some examples of template files are Twig [Twig] and Jinja2 [Jinja2].
Note: Additional TOSCA Artifact Types will be developed in future drafts of this specification.
This is the default (root) TOSCA Artifact Type definition that all other TOSCA base Artifact Types derive from.
|
tosca.artifacts.Root: description: The TOSCA Artifact Type all other TOSCA Artifact Types derive from |
This artifact type is used when an artifact definition needs to have its associated file simply treated as a file and no special handling/handlers are invoked (i.e., it is not treated as either an implementation or deployment artifact type).
|
Shorthand Name |
File |
|
Type Qualified Name |
tosca:File |
|
Type URI |
tosca.artifacts.File |
|
tosca.artifacts.File: derived_from: tosca.artifacts.Root |
This artifact type represents the parent type for all deployment artifacts in TOSCA. This class of artifacts typically represents a binary packaging of an application or service that is used to install/create or deploy it as part of a node’s lifecycle.
|
· TOSCA Orchestrators MAY throw an error if it encounters a non-normative deployment artifact type that it is not able to process.
This artifact type represents a parent type for any “image” which is an opaque packaging of a TOSCA Node’s deployment (whether real or virtual) whose contents are typically already installed and pre-configured (i.e., “stateful”) and prepared to be run on a known target container.
|
Shorthand Name |
Deployment.Image |
|
Type Qualified Name |
tosca:Deployment.Image |
|
Type URI |
tosca.artifacts.Deployment.Image |
|
tosca.artifacts.Deployment.Image: derived_from: tosca.artifacts.Deployment |
This artifact represents the parent type for all Virtual Machine (VM) image and container formatted deployment artifacts. These images contain a stateful capture of a machine (e.g., server) including operating system and installed software along with any configurations and can be run on another machine using a hypervisor which virtualizes typical server (i.e., hardware) resources.
|
tosca.artifacts.Deployment.Image.VM: derived_from: tosca.artifacts.Deployment.Image description: Virtual Machine (VM) Image |
· Future drafts of this specification may include popular standard VM disk image (e.g., ISO, VMI, VMDX, QCOW2, etc.) and container (e.g., OVF, bare, etc.) formats. These would include consideration of disk formats such as:
This artifact type represents the parent type for all implementation artifacts in TOSCA. These artifacts are used to implement operations of TOSCA interfaces either directly (e.g., scripts) or indirectly (e.g., config. files).
|
· TOSCA Orchestrators MAY throw an error if it encounters a non-normative implementation artifact type that it is not able to process.
This artifact type represents a Bash script type that contains Bash commands that can be executed on the Unix Bash shell.
|
Shorthand Name |
Bash |
|
Type Qualified Name |
tosca:Bash |
|
Type URI |
tosca.artifacts.Implementation.Bash |
|
tosca.artifacts.Implementation.Bash: derived_from: tosca.artifacts.Implementation description: Script artifact for the Unix Bash shell mime_type: application/x-sh file_ext: [ sh ] |
This artifact type represents a Python file that contains Python language constructs that can be executed within a Python interpreter.
|
Shorthand Name |
Python |
|
Type Qualified Name |
tosca:Python |
|
Type URI |
tosca.artifacts.Implementation.Python |
|
tosca.artifacts.Implementation.Python: derived_from: tosca.artifacts.Implementation description: Artifact for the interpreted Python language mime_type: application/x-python file_ext: [ py ] |
This artifact type represents the parent type for all template type artifacts in TOSCA. This class of artifacts typically represent template files that are dependent artifacts for implementation of an interface or deployment of a node.
Like the case of other dependent artifacts, the TOSCA orchestrator copies the dependent artifacts to the same location as the primary artifact for its access during execution. However, the template artifact processor need not be deployed in the environment where the primary artifact executes. At run time, the Orchestrator can invoke the artifact processor (i.e. template engine) to fill in run time values and provide the “filled template” to the primary artifact processor for further processing.
This reduces the requirements on the primary artifact target environment and the processing time of template artifacts.
|
This is the default (root) TOSCA Capability Type definition that all other TOSCA Capability Types derive from.
|
tosca.capabilities.Root: description: The TOSCA root Capability Type all other TOSCA Capability Types derive from |
The Node capability indicates the base capabilities of a TOSCA Node Type.
|
Shorthand Name |
Node |
|
Type Qualified Name |
tosca:Node |
|
Type URI |
tosca.capabilities.Node |
|
tosca.capabilities.Node: derived_from: tosca.capabilities.Root |
The Compute capability, when included on a Node Type or Template definition, indicates that the node can provide hosting on a named compute resource.
|
Shorthand Name |
Compute |
|
Type Qualified Name |
tosca:Compute |
|
Type URI |
tosca.capabilities.Compute |
|
Name |
Required |
Type |
Constraints |
Description |
|
name |
no |
None |
The otional name (or identifier) of a specific compute resource for hosting. |
|
|
num_cpus |
no |
greater_or_equal: 1 |
Number of (actual or virtual) CPUs associated with the Compute node. |
|
|
cpu_frequency |
no |
greater_or_equal: 0.1 GHz |
Specifies the operating frequency of CPU's core. This property expresses the expected frequency of one (1) CPU as provided by the property “num_cpus”. |
|
|
disk_size |
no |
greater_or_equal: 0 MB |
Size of the local disk available to applications running on the Compute node (default unit is MB). |
|
|
mem_size |
no |
greater_or_equal: 0 MB |
Size of memory available to applications running on the Compute node (default unit is MB). |
|
tosca.capabilities.Compute: derived_from: tosca.capabilities.Container properties: name: type: string required: false num_cpus: type: integer required: false constraints: - greater_or_equal: 1 cpu_frequency: type: scalar-unit.frequency required: false constraints: - greater_or_equal: 0.1 GHz disk_size: type: scalar-unit.size required: false constraints: - greater_or_equal: 0 MB mem_size: type: scalar-unit.size required: false constraints: - greater_or_equal: 0 MB |
The Storage capability, when included on a Node Type or Template definition, indicates that the node can provide addressiblity for the resource a named network with the specified ports.
|
Shorthand Name |
Network |
|
Type Qualified Name |
tosca:Network |
|
Type URI |
tosca.capabilities.Network |
|
Name |
Required |
Type |
Constraints |
Description |
|
name |
no |
string |
None |
The otional name (or identifier) of a specific network resource. |
|
tosca.capabilities.Network: derived_from: tosca.capabilities.Root properties: name: type: string required: false |
The Storage capability, when included on a Node Type or Template definition, indicates that the node can provide a named storage location with specified size range.
|
Shorthand Name |
Storage |
|
Type Qualified Name |
tosca:Storage |
|
Type URI |
tosca.capabilities.Storage |
|
Name |
Required |
Type |
Constraints |
Description |
|
name |
no |
string |
None |
The otional name (or identifier) of a specific storage resource. |
|
tosca.capabilities.Storage: derived_from: tosca.capabilities.Root properties: name: type: string required: false |
The Container capability, when included on a Node Type or Template definition, indicates that the node can act as a container for (or a host for) one or more other declared Node Types.
|
Shorthand Name |
Container |
|
Type Qualified Name |
tosca:Container |
|
Type URI |
tosca.capabilities.Container |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.capabilities.Container: derived_from: tosca.capabilities.Root |
This is the default TOSCA type that should be used or extended to define a network endpoint capability. This includes the information to express a basic endpoint with a single port or a complex endpoint with multiple ports. By default the Endpoint is assumed to represent an address on a private network unless otherwise specified.
|
Shorthand Name |
Endpoint |
|
Type Qualified Name |
tosca:Endpoint |
|
Type URI |
tosca.capabilities.Endpoint |
|
Name |
Required |
Type |
Constraints |
Description |
|
protocol |
yes |
default: tcp |
The name of the protocol (i.e., the protocol prefix) that the endpoint accepts (any OSI Layer 4-7 protocols)
Examples: http, https, ftp, tcp, udp, etc. |
|
|
port |
no |
greater_or_equal: 1 less_or_equal: 65535 |
The optional port of the endpoint. |
|
|
secure |
no |
default: false |
Requests for the endpoint to be secure and use credentials supplied on the ConnectsTo relationship. |
|
|
url_path |
no |
None |
The optional URL path of the endpoint’s address if applicable for the protocol. |
|
|
port_name |
no |
None |
The optional name (or ID) of the network port this endpoint should be bound to. |
|
|
network_name |
no |
default: PRIVATE |
The optional name (or ID) of the network this endpoint should be bound to. network_name: PRIVATE | PUBLIC |<network_name> | <network_id> |
|
|
initiator |
no |
one of: · source · target · peer
default: source |
The optional indicator of the direction of the connection. |
|
|
ports |
no |
None |
The optional map of ports the Endpoint supports (if more than one) |
|
Name |
Required |
Type |
Constraints |
Description |
|
ip_address |
yes |
None |
Note: This is the IP address as propagated up by the associated node’s host (Compute) container. |
|
tosca.capabilities.Endpoint: derived_from: tosca.capabilities.Root properties: protocol: type: string required: true default: tcp port: type: PortDef required: false secure: type: boolean required: false default: false url_path: type: string required: false port_name: type: string required: false network_name: type: string required: false default: PRIVATE initiator: type: string required: false default: source constraints: - valid_values: [ source, target, peer ] ports: type: map required: false constraints: - min_length: 1 entry_schema: type: PortSpec attributes: ip_address: type: string |
· Although both the port and ports properties are not required, one of port or ports must be provided in a valid Endpoint.
This capability represents a public endpoint which is accessible to the general internet (and its public IP address ranges).
This public endpoint capability also can be used to create a floating (IP) address that the underlying network assigns from a pool allocated from the application’s underlying public network. This floating address is managed by the underlying network such that can be routed an application’s private address and remains reliable to internet clients.
|
Shorthand Name |
Endpoint.Public |
|
Type Qualified Name |
tosca:Endpoint.Public |
|
Type URI |
tosca.capabilities.Endpoint.Public |
|
tosca.capabilities.Endpoint.Public: derived_from: tosca.capabilities.Endpoint properties: # Change the default network_name to use the first public network found network_name: type: string default: PUBLIC constraints: - equal: PUBLIC floating: description: > indicates that the public address should be allocated from a pool of floating IPs that are associated with the network. type: boolean default: false status: experimental dns_name: description: The optional name to register with DNS type: string required: false status: experimental |
· If the network_name is set to the reserved value PRIVATE or if the value is set to the name of network (or subnetwork) that is not public (i.e., has non-public IP address ranges assigned to it) then TOSCA Orchestrators SHALL treat this as an error.
· If a dns_name is set, TOSCA Orchestrators SHALL attempt to register the name in the (local) DNS registry for the Cloud provider.
This is the default TOSCA type that should be used or extended to define a specialized administrator endpoint capability.
|
Shorthand Name |
Endpoint.Admin |
|
Type Qualified Name |
tosca:Endpoint.Admin |
|
Type URI |
tosca.capabilities.Endpoint.Admin |
|
Name |
Required |
Type |
Constraints |
Description |
|
None |
N/A |
N/A |
N/A |
N/A |
|
tosca.capabilities.Endpoint.Admin: derived_from: tosca.capabilities.Endpoint # Change Endpoint secure indicator to true from its default of false properties: secure: type: boolean default: true constraints: - equal: true |
· TOSCA Orchestrator implementations of Endpoint.Admin (and connections to it) SHALL assure that network-level security is enforced if possible.
This is the default TOSCA type that should be used or extended to define a specialized database endpoint capability.
|
Shorthand Name |
Endpoint.Database |
|
Type Qualified Name |
tosca:Endpoint.Database |
|
Type URI |
tosca.capabilities.Endpoint.Database |
|
Name |
Required |
Type |
Constraints |
Description |
|
None |
N/A |
N/A |
N/A |
N/A |
|
tosca.capabilities.Endpoint.Database: derived_from: tosca.capabilities.Endpoint |
This is the default TOSCA type that should be used or extended to define an attachment capability of a (logical) infrastructure device node (e.g., BlockStorage node).
|
Shorthand Name |
Attachment |
|
Type Qualified Name |
tosca:Attachment |
|
Type URI |
tosca.capabilities.Attachment |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.capabilities.Attachment: derived_from: tosca.capabilities.Root |
This is the default TOSCA type that should be used to express an Operating System capability for a node.
|
Shorthand Name |
OperatingSystem |
|
Type Qualified Name |
tosca:OperatingSystem |
|
Type URI |
tosca.capabilities.OperatingSystem |
|
Name |
Required |
Type |
Constraints |
Description |
|
architecture |
no |
None |
The Operating System (OS) architecture.
Examples of valid values include: x86_32, x86_64, etc. |
|
|
type |
no |
None |
The Operating System (OS) type.
Examples of valid values include: linux, aix, mac, windows, etc. |
|
|
distribution |
no |
None |
The Operating System (OS) distribution.
Examples of valid values for an “type” of “Linux” would include: debian, fedora, rhel and ubuntu. |
|
|
version |
no |
None |
The Operating System version. |
|
tosca.capabilities.OperatingSystem: derived_from: tosca.capabilities.Root properties: architecture: type: string required: false type: type: string required: false distribution: type: string required: false version: type: version required: false |
· Please note that the string values for the properties architecture, type and distribution SHALL be normalized to lowercase by processors of the service template for matching purposes. For example, if a “type” value is set to either “Linux”, “LINUX” or “linux” in a service template, the processor would normalize all three values to “linux” for matching purposes.
This is the default TOSCA type that should be used to express a scalability capability for a node.
|
Shorthand Name |
Scalable |
|
Type Qualified Name |
tosca:Scalable |
|
Type URI |
tosca.capabilities.Scalable |
|
Name |
Required |
Type |
Constraints |
Description |
|
min_instances |
yes |
default: 1 |
This property is used to indicate the minimum number of instances that should be created for the associated TOSCA Node Template by a TOSCA orchestrator. |
|
|
max_instances |
yes |
default: 1 |
This property is used to indicate the maximum number of instances that should be created for the associated TOSCA Node Template by a TOSCA orchestrator. |
|
|
default_instances |
no |
N/A |
An optional property that indicates the requested default number of instances that should be the starting number of instances a TOSCA orchestrator should attempt to allocate.
Note: The value for this property MUST be in the range between the values set for ‘min_instances’ and ‘max_instances’ properties. |
|
tosca.capabilities.Scalable: derived_from: tosca.capabilities.Root properties: min_instances: type: integer default: 1 max_instances: type: integer default: 1 default_instances: type: integer |
· The actual number of instances for a node may be governed by a separate scaling policy which conceptually would be associated to either a scaling-capable node or a group of nodes in which it is defined to be a part of. This is a planned future feature of the TOSCA Simple Profile and not currently described.
A node type that includes the Bindable capability indicates that it can be bound to a logical network association via a network port.
|
Shorthand Name |
network.Bindable |
|
Type Qualified Name |
tosca:network.Bindable |
|
Type URI |
tosca.capabilities.network.Bindable |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.capabilities.network.Bindable: derived_from: tosca.capabilities.Node |
There are no normative Requirement Types currently defined in this working draft. Typically, Requirements are described against a known Capability Type
This is the default (root) TOSCA Relationship Type definition that all other TOSCA Relationship Types derive from.
|
Name |
Required |
Type |
Constraints |
Description |
|
tosca_id |
yes |
None |
A unique identifier of the realized instance of a Relationship Template that derives from any TOSCA normative type. |
|
|
tosca_name |
yes |
None |
This attribute reflects the name of the Relationship Template as defined in the TOSCA service template. This name is not unique to the realized instance model of corresponding deployed application as each template in the model can result in one or more instances (e.g., scaled) when orchestrated to a provider environment. |
|
|
state |
yes |
default: initial |
The state of the relationship instance. See section “Relationship States” for allowed values. |
|
tosca.relationships.Root: description: The TOSCA root Relationship Type all other TOSCA base Relationship Types derive from attributes: tosca_id: type: string tosca_name: type: string interfaces: Configure: |
This type represents a general dependency relationship between two nodes.
|
Shorthand Name |
DependsOn |
|
Type Qualified Name |
tosca:DependsOn |
|
Type URI |
tosca.relationships.DependsOn |
|
tosca.relationships.DependsOn: derived_from: tosca.relationships.Root valid_target_types: [ tosca.capabilities.Node ] |
This type represents a hosting relationship between two nodes.
|
Shorthand Name |
HostedOn |
|
Type Qualified Name |
tosca:HostedOn |
|
Type URI |
tosca.relationships.HostedOn |
|
tosca.relationships.HostedOn: derived_from: tosca.relationships.Root valid_target_types: [ tosca.capabilities.Container ] |
This type represents a network connection relationship between two nodes.
|
Shorthand Name |
ConnectsTo |
|
Type Qualified Name |
tosca:ConnectsTo |
|
Type URI |
tosca.relationships.ConnectsTo |
|
tosca.relationships.ConnectsTo: derived_from: tosca.relationships.Root valid_target_types: [ tosca.capabilities.Endpoint ] properties: credential: type: tosca.datatypes.Credential required: false |
|
Name |
Required |
Type |
Constraints |
Description |
|
credential |
no |
None |
The security credential to use to present to the target endpoint to for either authentication or authorization purposes. |
This type represents an attachment relationship between two nodes. For example, an AttachesTo relationship type would be used for attaching a storage node to a Compute node.
|
Shorthand Name |
AttachesTo |
|
Type Qualified Name |
tosca:AttachesTo |
|
Type URI |
tosca.relationships.AttachesTo |
|
Name |
Required |
Type |
Constraints |
Description |
|
location |
yes |
min_length: 1 |
The relative location (e.g., path on the file system), which provides the root location to address an attached node. e.g., a mount point / path such as ‘/usr/data’
Note: The user must provide it and it cannot be “root”. |
|
|
device |
no |
None |
The logical device name which for the attached device (which is represented by the target node in the model). e.g., ‘/dev/hda1’ |
|
Name |
Required |
Type |
Constraints |
Description |
|
device |
no |
None |
The logical name of the device as exposed to the instance. Note: A runtime property that gets set when the model gets instantiated by the orchestrator. |
|
tosca.relationships.AttachesTo: derived_from: tosca.relationships.Root valid_target_types: [ tosca.capabilities.Attachment ] properties: location: type: string constraints: - min_length: 1 device: type: string required: false |
This type represents an intentional network routing between two Endpoints in different networks.
|
Shorthand Name |
RoutesTo |
|
Type Qualified Name |
tosca:RoutesTo |
|
Type URI |
tosca.relationships.RoutesTo |
|
tosca.relationships.RoutesTo: derived_from: tosca.relationships.ConnectsTo valid_target_types: [ tosca.capabilities.Endpoint ] |
Interfaces are reusable entities that define a set of operations that that can be included as part of a Node type or Relationship Type definition. Each named operations may have code or scripts associated with them that orchestrators can execute for when transitioning an application to a given state.
· Designers of Node or Relationship types are not required to actually provide/associate code or scripts with every operation for a given interface it supports. In these cases, orchestrators SHALL consider that a “No Operation” or “no-op”.
· The default behavior when providing scripts for an operation in a sub-type (sub-class) or a template of an existing type which already has a script provided for that operation SHALL be override. Meaning that the subclasses’ script is used in place of the parent type’s script.
· When TOSCA Orchestrators substitute an implementation for an abstract node in a deployed service template it SHOULD be able to present a confirmation to the submitter to confirm the implementation chosen would be acceptable.
This is the default (root) TOSCA Interface Type definition that all other TOSCA Interface Types derive from.
|
tosca.interfaces.Root: derived_from: tosca.entity.Root description: The TOSCA root Interface Type all other TOSCA Interface Types derive from |
This lifecycle interface defines the essential, normative operations that TOSCA nodes may support.
|
Shorthand Name |
Standard |
|
Type Qualified Name |
tosca: Standard |
|
Type URI |
tosca.interfaces.node.lifecycle.Standard |
|
tosca.interfaces.node.lifecycle.Standard: derived_from: tosca.interfaces.Root create: description: Standard lifecycle create operation. configure: description: Standard lifecycle configure operation. start: description: Standard lifecycle start operation. stop: description: Standard lifecycle stop operation. delete: description: Standard lifecycle delete operation. |
The create operation is generally used to create the resource or service the node represents in the topology. TOSCA orchestrators expect node templates to provide either a deployment artifact or an implementation artifact of a defined artifact type that it is able to process. This specification defines normative deployment and implementation artifact types all TOSCA Orchestrators are expected to be able to process to support application portability.
TOSCA Orchestrators, when encountering a deployment artifact on the create operation; will automatically attempt to deploy the artifact based upon its artifact type. This means that no implementation artifacts (e.g., scripts) are needed on the create operation to provide commands that deploy or install the software.
For example, if a TOSCA Orchestrator is processing an application with a node of type SoftwareComponent and finds that the node’s template has a create operation that provides a filename (or references to an artifact which describes a file) of a known TOSCA deployment artifact type such as an Open Virtualization Format (OVF) image it will automatically deploy that image into the SoftwareComponent’s host Compute node.
The following diagrams show how TOSCA orchestrators sequence the operations of the Standard lifecycle in normal node startup and shutdown procedures.
The following key should be used to interpret the diagrams:
The following diagram shows how the TOSCA orchestrator would invoke operations
on the Standard lifecycle to startup a node.
The following diagram shows how the TOSCA orchestrator would invoke operations on the Standard lifecycle to shut down a node.
The lifecycle interfaces define the essential, normative operations that each TOSCA Relationship Types may support.
|
Shorthand Name |
Configure |
|
Type Qualified Name |
tosca:Configure |
|
Type URI |
tosca.interfaces.relationship.Configure |
|