tosca.interfaces.relationship.Configure: derived_from: tosca.interfaces.Root pre_configure_source: description: Operation to pre-configure the source endpoint. pre_configure_target: description: Operation to pre-configure the target endpoint. post_configure_source: description: Operation to post-configure the source endpoint. post_configure_target: description: Operation to post-configure the target endpoint. add_target: description: Operation to notify the source node of a target node being added via a relationship. add_source: description: Operation to notify the target node of a source node which is now available via a relationship. target_changed: description: Operation to notify source some property or attribute of the target changed remove_target: description: Operation to remove a target node. |
TOSCA relationships are directional connecting a source node to a target node. When TOSCA Orchestrator connects a source and target node together using a relationship that supports the Configure interface it will “interleave” the operations invocations of the Configure interface with those of the node’s own Standard lifecycle interface. This concept is illustrated below:
The following diagram shows how the TOSCA orchestrator would invoke Configure
lifecycle operations in conjunction with Standard lifecycle operations during a
typical startup sequence on a node.
Depending on which side (i.e., source or target) of a relationship a node is on, the orchestrator will:
· Invoke either the pre_configure_source or pre_configure_target operation as supplied by the relationship on the node.
· Invoke the node’s configure operation.
· Invoke either the post_configure_source or post_configure_target as supplied by the relationship on the node.
Note that the pre_configure_xxx and post_configure_xxx are invoked only once per node instance.
Since a topology template contains nodes that can dynamically be added (and scaled), removed or changed as part of an application instance, the Configure lifecycle includes operations that are invoked on node instances that to notify and address these dynamic changes.
For example, a source node, of a relationship that uses the Configure lifecycle, will have the relationship operations add_target, or remove_target invoked on it whenever a target node instance is added or removed to the running application instance. In addition, whenever the node state of its target node changes, the target_changed operation is invoked on it to address this change. Conversely, the add_source and remove_source operations are invoked on the source node of the relationship.
· The target (provider) MUST be active and running (i.e., all its dependency stack MUST be fulfilled) prior to invoking add_target
· In other words, all Requirements MUST be satisfied before it advertises its capabilities (i.e., the attributes of the matched Capabilities are available).
· In other words, it cannot be “consumed” by any dependent node.
· Conversely, since the source (consumer) needs information (attributes) about any targets (and their attributes) being removed before it actually goes away.
· The remove_target operation should only be executed if the target has had add_target executed. BUT in truth we’re first informed about a target in pre_configure_source, so if we execute that the source node should see remove_target called to cleanup.
· Error handling: If any node operation of the topology fails processing should stop on that node template and the failing operation (script) should return an error (failure) code when possible.
The TOSCA Root Node Type is the default type that all other TOSCA base Node Types derive from. This allows for all TOSCA nodes to have a consistent set of features for modeling and management (e.g., consistent definitions for requirements, capabilities and lifecycle interfaces).
|
Shorthand Name |
Root |
|
Type Qualified Name |
tosca:Root |
|
Type URI |
tosca.nodes.Root |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
The TOSCA Root Node type has no specified properties. |
|
Name |
Required |
Type |
Constraints |
Description |
|
tosca_id |
yes |
None |
A unique identifier of the realized instance of a Node Template that derives from any TOSCA normative type. |
|
|
tosca_name |
yes |
None |
This attribute reflects the name of the Node 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 node instance. See section “Node States” for allowed values. |
|
tosca.nodes.Root: derived_from: tosca.entity.Root description: The TOSCA Node Type all other TOSCA base Node Types derive from attributes: tosca_id: type: string tosca_name: type: string state: type: string capabilities: feature: type: tosca.capabilities.Node requirements: - dependency: capability: tosca.capabilities.Node node: tosca.nodes.Root relationship: tosca.relationships.DependsOn occurrences: [ 0, UNBOUNDED ] interfaces: Standard: |
· All Node Type definitions that wish to adhere to the TOSCA Simple Profile SHOULD extend from the TOSCA Root Node Type to be assured of compatibility and portability across implementations.
The TOSCA Abstract.Compute node represents an abstract compute resource without any requirements on storage or network resources.
|
Shorthand Name |
Abstract.Compute |
|
Type Qualified Name |
tosca:Abstract.Compute |
|
Type URI |
tosca.nodes.Abstract.Compute |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.nodes.Abstract.Compute: derived_from: tosca.nodes.Root capabilities: host: type: tosca.capabilities.Compute valid_source_types: [] |
The TOSCA Compute node represents one or more real or virtual processors of software applications or services along with other essential local resources. Collectively, the resources the compute node represents can logically be viewed as a (real or virtual) “server”.
|
Shorthand Name |
Compute |
|
Type Qualified Name |
tosca:Compute |
|
Type URI |
tosca.nodes.Compute |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
Name |
Required |
Type |
Constraints |
Description |
|
private_address |
no |
None |
The primary private IP address assigned by the cloud provider that applications may use to access the Compute node. |
|
|
public_address |
no |
None |
The primary public IP address assigned by the cloud provider that applications may use to access the Compute node. |
|
|
networks |
no |
map of NetworkInfo |
None |
The map of logical networks assigned to the compute host instance and information about them. |
|
ports |
no |
None |
The map of logical ports assigned to the compute host instance and information about them. |
|
tosca.nodes.Compute: derived_from: tosca.nodes.Abstract.Compute attributes: private_address: type: string public_address: type: string networks: type: map entry_schema: type: tosca.datatypes.network.NetworkInfo ports: type: map entry_schema: type: tosca.datatypes.network.PortInfo requirements: - local_storage: capability: tosca.capabilities.Attachment node: tosca.nodes.Storage.BlockStorage relationship: tosca.relationships.AttachesTo occurrences: [0, UNBOUNDED] capabilities: host: type: tosca.capabilities.Compute valid_source_types: [tosca.nodes.SoftwareComponent] endpoint: type: tosca.capabilities.Endpoint.Admin os: type: tosca.capabilities.OperatingSystem scalable: type: tosca.capabilities.Scalable binding: |
· The underlying implementation of the Compute node SHOULD have the ability to instantiate guest operating systems (either actual or virtualized) based upon the OperatingSystem capability properties if they are supplied in the a node template derived from the Compute node type.
The TOSCA SoftwareComponent node represents a generic software component that can be managed and run by a TOSCA Compute Node Type.
|
Shorthand Name |
SoftwareComponent |
|
Type Qualified Name |
tosca:SoftwareComponent |
|
Type URI |
tosca.nodes.SoftwareComponent |
|
Name |
Required |
Type |
Constraints |
Description |
|
component_version |
no |
None |
The optional software component’s version. |
|
|
admin_credential |
no |
Credential |
None |
The optional credential that can be used to authenticate to the software component. |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.nodes.SoftwareComponent: derived_from: tosca.nodes.Root properties: # domain-specific software component version component_version: type: version required: false admin_credential: type: tosca.datatypes.Credential required: false requirements: - host: capability: tosca.capabilities.Compute node: tosca.nodes.Compute relationship: tosca.relationships.HostedOn |
· Nodes that can directly be managed and run by a TOSCA Compute Node Type SHOULD extend from this type.
This TOSA WebServer Node Type represents an abstract software component or service that is capable of hosting and providing management operations for one or more WebApplication nodes.
|
Shorthand Name |
WebServer |
|
Type Qualified Name |
tosca:WebServer |
|
Type URI |
tosca.nodes.WebServer |
|
Name |
Required |
Type |
Constraints |
Description |
|
None |
N/A |
N/A |
N/A |
N/A |
|
tosca.nodes.WebServer: derived_from: tosca.nodes.SoftwareComponent capabilities: # Private, layer 4 endpoints data_endpoint: tosca.capabilities.Endpoint admin_endpoint: tosca.capabilities.Endpoint.Admin host: type: tosca.capabilities.Compute valid_source_types: [ tosca.nodes.WebApplication ] |
· This node SHALL export both a secure endpoint capability (i.e., admin_endpoint), typically for administration, as well as a regular endpoint (i.e., data_endpoint) for serving data.
The TOSCA WebApplication node represents a software application that can be managed and run by a TOSCA WebServer node. Specific types of web applications such as Java, etc. could be derived from this type.
|
Shorthand Name |
WebApplication |
|
Type Qualified Name |
tosca: WebApplication |
|
Type URI |
tosca.nodes.WebApplication |
|
Name |
Required |
Type |
Constraints |
Description |
|
context_root |
no |
None |
The web application’s context root which designates the application’s URL path within the web server it is hosted on. |
|
tosca.nodes.WebApplication: derived_from: tosca.nodes.Root properties: context_root: type: string capabilities: app_endpoint: type: tosca.capabilities.Endpoint requirements: - host: capability: tosca.capabilities.Compute node: tosca.nodes.WebServer relationship: tosca.relationships.HostedOn |
The TOSCA DBMS node represents a typical relational, SQL Database Management System software component or service.
|
Name |
Required |
Type |
Constraints |
Description |
|
root_password |
no |
None |
The optional root password for the DBMS server. |
|
|
port |
no |
None |
The DBMS server’s port. |
|
tosca.nodes.DBMS: derived_from: tosca.nodes.SoftwareComponent properties: root_password: type: string required: false description: the optional root password for the DBMS service port: type: integer required: false description: the port the DBMS service will listen to for data and requests capabilities: host: type: tosca.capabilities.Compute valid_source_types: [ tosca.nodes.Database ] |
The TOSCA Database node represents a logical database that can be managed and hosted by a TOSCA DBMS node.
|
Shorthand Name |
Database |
|
Type Qualified Name |
tosca:Database |
|
Type URI |
tosca.nodes.Database |
|
Name |
Required |
Type |
Constraints |
Description |
|
name |
yes |
None |
The logical database Name |
|
|
port |
no |
None |
The port the database service will use to listen for incoming data and requests. |
|
|
user |
no |
None |
The special user account used for database administration. |
|
|
password |
no |
None |
The password associated with the user account provided in the ‘user’ property. |
|
tosca.nodes.Database: derived_from: tosca.nodes.Root properties: name: type: string description: the logical name of the database port: type: integer description: the port the underlying database service will listen to for data user: type: string description: the optional user account name for DB administration required: false password: type: string description: the optional password for the DB user account required: false requirements: - host: capability: tosca.capabilities.Compute node: tosca.nodes.DBMS relationship: tosca.relationships.HostedOn capabilities: database_endpoint: |
The TOSCA Abstract.Storage node represents an abstract storage resource without any requirements on compute or network resources.
|
Shorthand Name |
AbstractStorage |
|
Type Qualified Name |
tosca:Abstract.Storage |
|
Type URI |
tosca.nodes.Abstract.Storage |
|
Name |
Required |
Type |
Constraints |
Description |
|
name |
yes |
None |
The logical name (or ID) of the storage resource. |
|
|
size |
no |
greater_or_equal: 0 MB |
The requested initial storage size (default unit is in Gigabytes). |
|
tosca.nodes.Abstract.Storage: derived_from: tosca.nodes.Root properties: name: type: string size: type: scalar-unit.size default: 0 MB constraints: - greater_or_equal: 0 MB capabilities: # TBD |
The TOSCA ObjectStorage node represents storage that provides the ability to store data as objects (or BLOBs of data) without consideration for the underlying filesystem or devices.
|
Shorthand Name |
ObjectStorage |
|
Type Qualified Name |
tosca:ObjectStorage |
|
Type URI |
tosca.nodes.Storage.ObjectStorage |
|
Name |
Required |
Type |
Constraints |
Description |
|
maxsize |
no |
greater_or_equal: 1 GB |
The requested maximum storage size (default unit is in Gigabytes). |
|
tosca.nodes.Storage.ObjectStorage: derived_from: tosca.nodes.Abstract.Storage properties: maxsize: type: scalar-unit.size constraints: - greater_or_equal: 0 GB capabilities: storage_endpoint: |
· Subclasses of the tosca.nodes.Storage.ObjectStorage node type may impose further constraints on properties. For example, a subclass may constrain the (minimum or maximum) length of the ‘name’ property or include a regular expression to constrain allowed characters used in the ‘name’ property.
The TOSCA BlockStorage node currently represents a server-local block storage device (i.e., not shared) offering evenly sized blocks of data from which raw storage volumes can be created.
Note: In this draft of the TOSCA Simple Profile, distributed or Network Attached Storage (NAS) are not yet considered (nor are clustered file systems), but the TC plans to do so in future drafts.
|
Shorthand Name |
BlockStorage |
|
Type Qualified Name |
tosca:BlockStorage |
|
Type URI |
tosca.nodes.Storage.BlockStorage |
|
Name |
Required |
Type |
Constraints |
Description |
|
size |
yes * |
greater_or_equal: 1 MB |
The requested storage size (default unit is MB). * Note: · Required when an existing volume (i.e., volume_id) is not available. · If volume_id is provided, size is ignored. Resize of existing volumes is not considered at this time. |
|
|
volume_id |
no |
None |
ID of an existing volume (that is in the accessible scope of the requesting application). |
|
|
snapshot_id |
no |
None |
Some identifier that represents an existing snapshot that should be used when creating the block storage (volume). |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.nodes.Storage.BlockStorage: derived_from: tosca.nodes.Abstract.Storage properties: volume_id: type: string required: false snapshot_id: type: string required: false capabilities: attachment: |
· The size property is required when an existing volume (i.e., volume_id) is not available. However, if the property volume_id is provided, the size property is ignored.
· Resize is of existing volumes is not considered at this time.
· It is assumed that the volume contains a single filesystem that the operating system (that is hosting an associate application) can recognize and mount without additional information (i.e., it is operating system independent).
· Currently, this version of the Simple Profile does not consider regions (or availability zones) when modeling storage.
The TOSCA Container Runtime node represents operating system-level virtualization technology used to run multiple application services on a single Compute host.
|
Shorthand Name |
Container.Runtime |
|
Type Qualified Name |
tosca:Container.Runtime |
|
Type URI |
tosca.nodes.Container.Runtime |
|
tosca.nodes.Container.Runtime: derived_from: tosca.nodes.SoftwareComponent capabilities: host: type: tosca.capabilities.Compute valid_source_types: [tosca.nodes.Container.Application] scalable: |
The TOSCA Container Application node represents an application that requires Container-level virtualization technology.
|
Shorthand Name |
Container.Application |
|
Type Qualified Name |
tosca:Container.Application |
|
Type URI |
tosca.nodes.Container.Application |
|
tosca.nodes.Container.Application: derived_from: tosca.nodes.Root requirements: - host: capability: tosca.capabilities.Compute node: tosca.nodes.Container.Runtime relationship: tosca.relationships.HostedOn - storage: capability: tosca.capabilities.Storage - network: capability: tosca.capabilities.Endpoint |
The TOSCA Load Balancer node represents logical function that be used in conjunction with a Floating Address to distribute an application’s traffic (load) across a number of instances of the application (e.g., for a clustered or scaled application).
|
Shorthand Name |
LoadBalancer |
|
Type Qualified Name |
tosca:LoadBalancer |
|
Type URI |
tosca.nodes.LoadBalancer |
|
tosca.nodes.LoadBalancer: derived_from: tosca.nodes.Root properties: algorithm: type: string required: false status: experimental capabilities: client: type: tosca.capabilities.Endpoint.Public occurrences: [0, UNBOUNDED] description: the Floating (IP) client’s on the public network can connect to requirements: - application: capability: tosca.capabilities.Endpoint relationship: tosca.relationships.RoutesTo occurrences: [0, UNBOUNDED] description: Connection to one or more load balanced applications |
· A LoadBalancer node can still be instantiated and managed independently of any applications it would serve; therefore, the load balancer’s application requirement allows for zero occurrences.
TOSCA Group Types represent logical groupings of TOSCA nodes that have an implied membership relationship and may need to be orchestrated or managed together to achieve some result. Some use cases being developed by the TOSCA TC use groups to apply TOSCA policies for software placement and scaling while other use cases show groups can be used to describe cluster relationships.
Note: Additional normative TOSCA Group Types and use cases for them will be developed in future drafts of this specification.
This is the default (root) TOSCA Group Type definition that all other TOSCA base Group Types derive from.
|
tosca.groups.Root: description: The TOSCA Group Type all other TOSCA Group Types derive from interfaces: Standard: |
· Group operations are not necessarily tied directly to member nodes that are part of a group.
· Future versions of this specification will create sub types of the tosca.groups.Root type that will describe how Group Type operations are to be orchestrated.
TOSCA Policy Types represent logical grouping of TOSCA nodes that have an implied relationship and need to be orchestrated or managed together to achieve some result. Some use cases being developed by the TOSCA TC use groups to apply TOSCA policies for software placement and scaling while other use cases show groups can be used to describe cluster relationships.
This is the default (root) TOSCA Policy Type definition that all other TOSCA base Policy Types derive from.
|
tosca.policies.Root: description: The TOSCA Policy Type all other TOSCA Policy Types derive from |
This is the default (root) TOSCA Policy Type definition that is used to govern placement of TOSCA nodes or groups of nodes.
|
tosca.policies.Placement: derived_from: tosca.policies.Root description: The TOSCA Policy Type definition that is used to govern placement of TOSCA nodes or groups of nodes. |
This is the default (root) TOSCA Policy Type definition that is used to govern scaling of TOSCA nodes or groups of nodes.
|
tosca.policies.Scaling: derived_from: tosca.policies.Root description: The TOSCA Policy Type definition that is used to govern scaling of TOSCA nodes or groups of nodes. |
This is the default (root) TOSCA Policy Type definition that is used to govern update of TOSCA nodes or groups of nodes.
|
tosca.policies.Update: derived_from: tosca.policies.Root description: The TOSCA Policy Type definition that is used to govern update of TOSCA nodes or groups of nodes. |
This is the default (root) TOSCA Policy Type definition that is used to declare performance requirements for TOSCA nodes or groups of nodes.
|
tosca.policies.Performance: derived_from: tosca.policies.Root description: The TOSCA Policy Type definition that is used to declare performance requirements for TOSCA nodes or groups of nodes. |
Except for the examples, this section is normative and defines changes to the TOSCA archive format relative to the TOSCA v1.0 XML specification.
TOSCA Simple Profile definitions along with all accompanying artifacts (e.g. scripts, binaries, configuration files) can be packaged together in a CSAR file as already defined in the TOSCA version 1.0 specification [TOSCA-1.0]. In contrast to the TOSCA 1.0 CSAR file specification (see chapter 16 in [TOSCA-1.0]), this simple profile makes a few simplifications both in terms of overall CSAR file structure as well as meta-file content as described below.
A CSAR zip file is required to contain one of the following:
· a TOSCA-Metadata directory, which in turn contains the TOSCA.meta metadata file that provides entry information for a TOSCA orchestrator processing the CSAR file.
· a yaml (.yml or .yaml) file at the root of the archive. The yaml file being a valid tosca definition template that MUST define a metadata section where template_name and template_version are required.
The CSAR file may contain other directories with arbitrary names and contents. Note that in contrast to the TOSCA 1.0 specification, it is not required to put TOSCA definitions files into a special “Definitions” directory, but definitions YAML files can be placed into any directory within the CSAR file.
The TOSCA.meta file structure follows the exact same syntax as defined in the TOSCA 1.0 specification. However, it is only required to include block_0 (see section 16.2 in [TOSCA-1.0]) with the Entry-Definitions keyword pointing to a valid TOSCA definitions YAML file that a TOSCA orchestrator should use as entry for parsing the contents of the overall CSAR file.
Note that it is not required to explicitly list TOSCA definitions files in subsequent blocks of the TOSCA.meta file, but any TOSCA definitions files besides the one denoted by the Entry-Definitions keyword can be found by a TOSCA orchestrator by processing respective imports statements in the entry definitions file (or in recursively imported files).
Note also that any additional artifact files (e.g. scripts, binaries, configuration files) do not have to be declared explicitly through blocks in the TOSCA.meta file. Instead, such artifacts will be fully described and pointed to by relative path names through artifact definitions in one of the TOSCA definitions files contained in the CSAR.
Due to the simplified structure of the CSAR file and TOSCA.meta file compared to TOSCA 1.0, the CSAR-Version keyword listed in block_0 of the meta-file is required to denote version 1.1.
The Other-Definitions key in block_0 is used to declare an unambiguous set of files containing substitution templates that can be used to implement nodes defined in the main template (i.e. the file declared in Entry-Definitions). Thus, all the topology templates defined in files listed under the Other-Definitions key are to be used only as substitution templates, and not as standalone services. If such a topology template cannot act as a substitution template, it will be ignored by the orchestrator.
The value of the Other-Definitions key is a list of filenames relative to the root of the CSAR archive delimited by a blank space. If the filenames contain spaces, the filename should be enclosed by double quotation marks (“). Note that according to the TOSCA.meta structure definition, a value can extend in a new line as long as the new line starts with a blank space.
Due to the changes to the TOSCA.meta file compared to TOSCA 1.2 the TOSCA-Meta-File-Version keyword listed in block_0 of the the meta-file is required to denote version 1.1.
Besides using the normative keynames in block_0 (i.e. TOSCA-Meta-File-Version, CSAR-Version,
Created-By, Entry-Definitions, Other-Definitions) users can populate further blocks in the TOSCA.meta file with custom key-value pairs that follow the entry syntax of the TOSCA.meta file, but which are outside the scope of the TOSCA specifications.
Nevertheless, future versions of the TOSCA specification may add definitions of new keynames to be used in the TOSCA.meta file. In case of a keyname collision (with a custom keyname) the TOSCA specification definitions take precedence.
To minimize such keyname collisions the specification reserves the use of keynames starting with “TOSCA” and “tosca” (the strings within, but not including, the double quotation marks). It is recommended as a good practice to use a specific prefix (e.g. identifying the organization, scope, etc.) when using custom keynames.
The following listing represents a valid TOSCA.meta file according to this TOSCA Simple Profile specification.
|
TOSCA-Meta-File-Version: 1.1 CSAR-Version: 1.1 Created-By: OASIS TOSCA TC Entry-Definitions: definitions/tosca_elk.yaml Other-Definitions: definitions/tosca_moose.yaml definitions/tosca_deer.yaml |
This TOSCA.meta file indicates its simplified TOSCA Simple Profile structure by means of the CSAR-Version keyword with value 1.1. The Entry-Definitions keyword points to a TOSCA definitions YAML file with the name tosca_elk.yaml which is contained in a directory called definitions within the root of the CSAR file. Additionally, it specifies that substitution templates can be found in the files tosca_moose.yaml and tosca_deer.yaml also found in the directory called defintions in the root of the CSAR file.
In case the archive doesn’t contains a TOSCA-Metadata directory the archive is required to contains a single YAML file at the root of the archive (other templates may exits in sub-directories).
This file must be a valid TOSCA definitions YAML file with the additional restriction that the metadata section (as defined in <IP_ADDRESS>) is required and template_name and template_version metadata are also required.
TOSCA processors should recognized this file as being the CSAR Entry-Definitions file. The CSAR-Version is defined by the template_version metadata section. The Created-By value is defined by the template_author metadata.
Note that in an archive without TOSCA-metadata it is not possible to unambiguously include defintions for substitution templates as we can have only one topology template defined in a yaml file.
The following represents a valid TOSCA template file acting as the CSAR Entry-Definitions file in an archive without TOSCA-Metadata directory.
|
tosca_definitions_version: tosca_simple_yaml_1_3
metadata: template_name: my_template template_author: OASIS TOSCA TC template_version: 1.0 |
TOSCA defines two different kinds of workflows that can be used to deploy (instantiate and start), manage at runtime or undeploy (stop and delete) a TOSCA topology: declarative workflows and imperative workflows. Declarative workflows are automatically generated by the TOSCA orchestrator based on the nodes, relationships, and groups defined in the topology. Imperative workflows are manually specified by the author of the topology and allows the specification of any use-case that has not been planned in the definition of node and relationships types or for advanced use-case (including reuse of existing scripts and workflows).
Workflows can be triggered on deployment of a topology (deploy workflow) on undeployment (undeploy workflow) or during runtime, manually, or automatically based on policies defined for the topology.
Note: The TOSCA orchestrators will execute a single workflow at a time on a topology to guarantee that the defined workflow can be consistent and behave as expected.
TOSCA defines several normative workflows that are used to operate a Topology. That is, reserved names of workflows that should be preserved by TOSCA orchestrators and that, if specified in the topology will override the workflow generated by the orchestrator :
· deploy: is the workflow used to instantiate and perform the initial deployment of the topology.
· undeploy: is the workflow used to remove all instances of a topology.
Future versions of the specification will describe the normative naming and declarative generation of additional workflows used to operate the topology at runtime.
· scaling workflows: defined for every scalable nodes or based on scaling policies
· auto-healing workflows: defined in order to restart nodes that may have failed
Declarative workflows are the result of the weaving of topology’s node, relationships, and groups workflows.
The weaving process generates the workflow of every single node in the topology, insert operations from the relationships and groups and finally add ordering consideration. The weaving process will also take care of the specific lifecycle of some nodes and the TOSCA orchestrator is responsible to trigger errors or warnings in case the weaving cannot be processed or lead to cycles for example.
This section aims to describe and explain how a TOSCA orchestrator will generate a workflow based on the topology entities (nodes, relationships and groups).
This section details specific constraints and considerations that applies during the weaving process.
When a node is abstract the orchestrator is responsible for providing a valid matching resources for the node in order to deploy the topology. This consideration is also valid for dangling requirements (as they represents a quick way to define an actual node).
The lifecycle of such nodes is the responsibility of the orchestrator and they may not answer to the normative TOSCA lifecycle. Their workflow is considered as "delegate" and acts as a black-box between the initial and started state in the install workflow and the started to deleted states in the uninstall workflow.
If a relationship to some of this node defines operations or lifecycle dependency constraint that relies on intermediate states, the weaving SHOULD fail and the orchestrator SHOULD raise an error.
This section explains how relationships impacts the workflow generation to enable the composition of complex topologies.
The depends on relationship is used to establish a dependency from a node to another. A source node that depends on a target node will be created only after the other entity has been started.
DependsOn relationship SHOULD not be implemented. Even if the Configure interface can be implemented this is not considered as a best-practice. If you need specific implementation, please have a look at the ConnectsTo relationship.
This example show the usage of a generic DependsOn relationship between two custom software components.
In this example the relationship configure interface doesn’t define operations so they don’t appear in the generated lifecycle.
The connects to relationship is similar to the DependsOn relationship except that it is intended to provide an implementation. The difference is more theoretical than practical but helps users to make an actual distinction from a meaning perspective.
The hosted_on dependency relationship allows to define a hosting relationship between an entity and another. The hosting relationship has multiple impacts on the workflow and execution:
· The implementation artifacts of the source node is executed on the same host as the one of the target node.
· The create operation of the source node is executed only once the target node reach the started state.
· When multiple nodes are hosted on the same host node, the defined operations will not be executed concurrently even if the theoretical workflow could allow it (actual generated workflow will avoid concurrency).
This example explain the TOSCA weaving operation of a custom SoftwareComponent on a tosca.nodes.Compute instance. The compute node is an orchestrator provided node meaning that it’s lifecycle is delegated to the orchestrator. This is a black-box and we just expect a started compute node to be provided by the orchestrator.
The software node lifecycle operations will be executed on the Compute node (host) instance.
Tosca allows some more complex hosting scenarios where a software component could be hosted on another software component.
In such scenarios the software create operation is triggered only once the software_base node has reached the started state.
This example illustrate concurrency constraint introduced by the management of multiple nodes on a single compute.
TOSCA implementation currently does not allow concurrent executions of scripts implementation artifacts (shell, python, ansible, puppet, chef etc.) on a given host. This limitation is not applied on multiple hosts. This limitation is expressed through the HostedOn relationship limitation expressing that when multiple components are hosted on a given host node then their operations will not be performed concurrently (generated workflow will ensure that operations are not concurrent).
When a node depends on another node no operations will be processed concurrently. In some situations, especially when the two nodes lies on different hosts we could expect the create operation to be executed concurrently for performance optimization purpose. The current version of the specification will allow to use imperative workflows to solve this use-case. However, this scenario is one of the scenario that we want to improve and handle in the future through declarative workflows.
The current ConnectsTo workflow implies that the target node is started before the source node is even created. This means that pre_configure_target and post_configure_target operations cannot use any input based on source attribute. It is however possible to refer to get_property inputs based on source properties. For advanced configurations the add_source operation should be used.
Note also that future plans on declarative workflows improvements aims to solve this kind of issues while it is currently possible to use imperative workflows.
Imperative workflows are user defined and can define any really specific constraints and ordering of activities. They are really flexible and powerful and can be used for any complex use-case that cannot be solved in declarative workflows. However, they provide less reusability as they are defined for a specific topology rather than being dynamically generated based on the topology content.
Imperative workflow grammar defines two ways to define the sequence of operations in an imperative workflow:
· Leverage the on_success definition to define the next steps that will be executed in parallel.
· Leverage a sequence of activity in a step.
The graph of workflow steps is build based on the values of on_success elements of the various defined steps. The graph is built based on the following rules:
· All steps that defines an on_success operation must be executed before the next step can be executed. So if A and C defines an on_success operation to B, then B will be executed only when both A and C have been successfully executed.
· The multiple nodes defined by an on_success construct can be executed in parallel.
· Every step that doesn’t have any predecessor is considered as an initial step and can run in parallel.
· Every step that doesn’t define any successor is considered as final. When all the final nodes executions are completed then the workflow is considered as completed.
The following example defines multiple steps and the on_success relationship between them.
|
topology_template: workflows: deploy: description: Workflow to deploy the application steps: A: on_success: - B - C B: on_success: - D C: on_success: - D D: E: on_success: - C - F F: |
The following schema is the visualization of the above definition in term of sequencing of the steps.
The step definition of a TOSCA imperative workflow allows multiple activities to be defined :
|
workflows: my_workflow: steps: create_my_node: target: my_node activities: - set_state: creating - call_operation: tosca.interfaces.node.lifecycle.Standard.create - set_state: created |
The sequence defined here defines three different activities that will be performed in a sequential way. This is just equivalent to writing multiple steps chained by an on_success together :
|
workflows: my_workflow: steps: creating_my_node: target: my_node activities: - set_state: creating on_success: create_my_node create_my_node: target: my_node activities: - call_operation: tosca.interfaces.node.lifecycle.Standard.create on_success: created_my_node created_my_node: target: my_node activities: - set_state: created |
In both situations the resulting workflow is a sequence of activities:
Imperative workflow allow user to define custom workflows allowing them to add operations that are not normative, or for example, to execute some operations in parallel when TOSCA would have performed sequential execution.
As Imperative workflows are related to a topology, adding a workflow is as simple as adding a workflows section to your topology template and specifying the workflow and the steps that compose it.
This sample topology add a very simple custom workflow to trigger the mysql backup operation.
|
topology_template: node_templates: my_server: type: tosca.nodes.Compute mysql: type: tosca.nodes.DBMS.MySQL requirements: - host: my_server interfaces: tosca.interfaces.nodes.custom.Backup: operations: backup: backup.sh workflows: backup: description: Performs a snapshot of the MySQL data. steps: my_step: target: mysql activities: - call_operation: tosca.interfaces.nodes.custom.Backup.backup |
In such topology the TOSCA container will still use declarative workflow to generate the deploy and undeploy workflows as they are not specified and a backup workflow will be available for user to trigger.
TOSCA declarative workflow generation constraint the workflow so that no operations are called in parallel on the same host. Looking at the following topology this means that the mysql and tomcat nodes will not be created in parallel but sequentially. This is fine in most of the situations as packet managers like apt or yum doesn’t not support concurrency, however if both create operations performs a download of zip package from a server most of people will hope to do that in parallel in order to optimize throughput.
Imperative workflows can help to solve this issue. Based on the above topology we will design a workflow that will create tomcat and mysql in parallel but we will also ensure that tomcat is started after mysql is started even if no relationship is defined between the components:
To achieve such workflow, the following topology will be defined:
|
topology_template: node_templates: my_server: type: tosca.nodes.Compute mysql: type: tosca.nodes.DBMS.MySQL requirements: - host: my_server tomcat: type: tosca.nodes.WebServer.Tomcat requirements: - host: my_server workflows: deploy: description: Override the TOSCA declarative workflow with the following. steps: compute_install target: my_server activities: - delegate: deploy on_success: - mysql_install - tomcat_install tomcat_install: target: tomcat activities: - set_state: creating - call_operation: tosca.interfaces.node.lifecycle.Standard.create - set_state: created on_success: - tomcat_starting mysql_install: target: mysql activities: - set_state: creating - call_operation: tosca.interfaces.node.lifecycle.Standard.create - set_state: created - set_state: starting - call_operation: tosca.interfaces.node.lifecycle.Standard.start - set_state: started on_success: - tomcat_starting tomcat_starting: target: tomcat activities: - set_state: starting - call_operation: tosca.interfaces.node.lifecycle.Standard.start - set_state: started |
Pre conditions allows the TOSCA orchestrator to determine if a workflow can be executed based on the states and attribute values of the topology’s node. Preconditions must be added to the initial workflow.
In this example we will use precondition so that we make sure that the mysql node is in the correct state for a backup.
|
topology_template: node_templates: my_server: type: tosca.nodes.Compute mysql: type: tosca.nodes.DBMS.MySQL requirements: - host: my_server interfaces: tosca.interfaces.nodes.custom.Backup: operations: backup: backup.sh workflows: backup: description: Performs a snapshot of the MySQL data. preconditions: - target: my_server condition: - assert: - state: [{equal: available}] - target: mysql condition: - assert: - state: [{valid_values: [started, available]}] - my_attribute: [{equal: ready }] steps: my_step: target: mysql activities: - call_operation: tosca.interfaces.nodes.custom.Backup.backup |
When the backup workflow will be triggered (by user or policy) the TOSCA engine will first check that preconditions are fulfilled. In this situation the engine will check that my_server node is in available state AND that mysql node is in started OR available states AND that mysql my_attribute value is equal to ready.
TOSCA allows the reusability of a workflow in other workflows. Such concepts can be achieved thanks to the inline activity.
The following example show how a workflow can inline an existing workflow and reuse it.
|
topology_template: node_templates: my_server: type: tosca.nodes.Compute mysql: type: tosca.nodes.DBMS.MySQL requirements: - host: my_server interfaces: tosca.interfaces.nodes.custom.Backup: operations: backup: backup.sh workflows: start_mysql: steps: start_mysql: target: mysql activities : - set_state: starting - call_operation: tosca.interfaces.node.lifecycle.Standard.start - set_state: started stop_mysql: steps: stop_mysql: target: mysql activities: - set_state: stopping - call_operation: tosca.interfaces.node.lifecycle.Standard.stop - set_state: stopped
backup: description: Performs a snapshot of the MySQL data. preconditions: - target: my_server condition: - assert: - state: [{equal: available}] - target: mysql condition: - assert: - state: [{valid_values: [started, available]}] - my_attribute: [{equal: ready }] steps: backup_step: activities: - inline: stop - call_operation: tosca.interfaces.nodes.custom.Backup.backup - inline: start restart: steps: backup_step: activities: - inline: stop - inline: start |
The example above defines three workflows and show how the start_mysql and stop_mysql workflows are reused in the backup and restart workflows.
Inlined workflows are inlined sequentially in the existing workflow for example the backup workflow would look like this:
It is possible of course to inline more complex workflows. The following example defines an inlined workflows with multiple steps including concurrent steps:
|
topology_template: workflows: inlined_wf: steps: A: target: node_a activities: - call_operation: a on_success: - B - C B: target: node_a activities: - call_operation: b on_success: - D C: target: node_a activities: - call_operation: c on_success: - D D: target: node_a activities: - call_operation: d E: target: node_a activities: - call_operation: e on_success: - C - F F: target: node_a activities: - call_operation: f main_workflow: steps: G: target: node_a activities: - set_state: initial - inline: inlined_wf - set_state: available
|
To describe the following workflow:
Preconditions are used to validate if the workflow should be executed only for the initial workflow. If a workflow that is inlined defines some preconditions theses preconditions will be used at the instance level to define if the operations should be executed or not on the defined instance.
This construct can be used to filter some steps on a specific instance or under some specific circumstances or topology state.
|
topology_template: node_templates: my_server: type: tosca.nodes.Compute cluster: type: tosca.nodes.DBMS.Cluster requirements: - host: my_server interfaces: tosca.interfaces.nodes.custom.Backup: operations: backup: backup.sh workflows: backup: description: Performs a snapshot of the MySQL data. preconditions: - target: my_server condition: - assert: - state: [{equal: available}] - target: mysql condition: - assert: - state: [{valid_values: [started, available]}] - my_attribute: [{equal: ready }] steps: backup_step: target: cluster filter: # filter is a list of clauses. Matching between clauses is and. - or: # only one of sub-clauses must be true. - assert: - foo: [{equals: true}] - assert: - bar: [{greater_than: 2}, {less_than: 20}] activities: - call_operation: tosca.interfaces.nodes.custom.Backup.backup |
Inputs can be defined in a workflow and will be provided in the execution context of the workflow. If an operation defines a get_input function on one of its parameter the input will be retrieved from the workflow input, and if not found from the topology inputs.
|
topology_template: node_templates: my_server: type: tosca.nodes.Compute mysql: type: tosca.nodes.DBMS.MySQL requirements: - host: my_server interfaces: tosca.interfaces.nodes.custom.Backup: operations: backup: implementation: backup.sh inputs: storage_url: { get_input: storage_url } workflows: backup: description: Performs a snapshot of the MySQL data. preconditions: - target: my_server valid_states: [available] - target: mysql valid_states: [started, available] attributes: my_attribute: [ready] inputs: storage_url: type: string steps: my_step: target: mysql activities: - call_operation: tosca.interfaces.nodes.custom.Backup.backup |
To trigger such a workflow, the TOSCA engine must allow user to provide inputs that match the given definitions.
By default, failure of any activity of the workflow will result in the failure of the workflow and will results in stopping the steps to be executed.
Exception: uninstall workflow operation failure SHOULD not prevent the other operations of the workflow to run (a failure in an uninstall script SHOULD not prevent from releasing resources from the cloud).
For any workflow other than install and uninstall failures may leave the topology in an unknown state. In such situation the TOSCA engine may not be able to orchestrate the deployment. Implementation of on_failure construct allows to execute rollback operations and reset the state of the affected entities back to an orchestrator known state.
|
topology_template: node_templates: my_server: type: tosca.nodes.Compute mysql: type: tosca.nodes.DBMS.MySQL requirements: - host: my_server interfaces: tosca.interfaces.nodes.custom.Backup: operations: backup: implementation: backup.sh inputs: storage_url: { get_input: storage_url } workflows: backup: steps: backup_step: target: mysql activities: - set_state: backing_up # this state is not a TOSCA known state - call_operation: tosca.interfaces.nodes.custom.Backup.backup - set_state: available # this state is known by TOSCA orchestrator on_failure: - rollback_step rollback_step: target: mysql activities: - call_operation: tosca.interfaces.nodes.custom.Backup.backup - set_state: available # this state is known by TOSCA orchestrator |
7.3.8 Use a custom workflow language
TOSCA orchestrators may support additional workflow languages beyond the one which has been described in this specification.
|
topology_template: workflows: my_workflow: implementation: my_workflow.bpmn.xml |
The implementation refers to the artifact my_workflow.bpmn.xml containing the workflow definition written in BPMN (Business Process Modeling Notation).
|
topology_template: workflows: my_workflow: implementation: description: workflow implemented in Mistral type: mycompany.artifacts.Implementation.Mistral file: my_workflow.workbook.mistral.yaml |
The implementation refers to the artifact my_workflow_script which is in fact a Mistral workbook written in the Mistral workflow definition language.
Except for the examples, this section is normative and describes how to express and control the application centric network semantics available in TOSCA.
TOSCA Service Templates are application centric in the sense that they focus on describing application components in terms of their requirements and interrelationships. In order to provide cloud portability, it is important that a TOSCA Service Template avoid cloud specific requirements and details. However, at the same time, TOSCA must provide the expressiveness to control the mapping of software component connectivity to the network constructs of the hosting cloud.
TOSCA Networking takes the following approach.
1. The application component connectivity semantics and expressed in terms of Requirements and Capabilities and the relationships between these. Service Template authors are able to express the interconnectivity requirements of their software components in an abstract, declarative, and thus highly portable manner.
2. The information provided in TOSCA is complete enough for a TOSCA implementation to fulfill the application component network requirements declaratively (i.e., it contains information such as communication initiation and layer 4 port specifications) so that the required network semantics can be realized on arbitrary network infrastructures.
3. TOSCA Networking provides full control of the mapping of software component interconnectivity to the networking constructs of the hosting cloud network independently of the Service Template, providing the required separation between application and network semantics to preserve Service Template portability.
4. Service Template authors have the choice of specifying application component networking requirements in the Service Template or completely separating the application component to network mapping into a separate document. This allows application components with explicit network requirements to express them while allowing users to control the complete mapping for all software components which may not have specific requirements. Usage of these two approaches is possible simultaneously and required to avoid having to re-write components network semantics as arbitrary sets of components are assembled into Service Templates.
5. Defining a set of network semantics which are expressive enough to address the most common application connectivity requirements while avoiding dependencies on specific network technologies and constructs. Service Template authors and cloud providers are able to express unique/non-portable semantics by defining their own specialized network Requirements and Capabilities.
TOSCA’s application centric approach includes the modeling of network connectivity semantics from an application component connectivity perspective. The basic premise is that applications contain components which need to communicate with other components using one or more endpoints over a network stack such as TCP/IP, where connectivity between two components is expressed as a <source component, source address, source port, target component, target address, target port> tuple. Note that source and target components are added to the traditional 4 tuple to provide the application centric information, mapping the network to the source or target component involved in the connectivity.
Software components are expressed as Node Types in TOSCA which can express virtually any kind of concept in a TOSCA model. Node Types offering network based functions can model their connectivity using a special Endpoint Capability, tosca.capabilities.Endpoint, designed for this purpose. Node Types which require an Endpoint can specify this as a TOSCA requirement. A special Relationship Type, tosca.relationships.ConnectsTo, is used to implicitly or explicitly relate the source Node Type’s endpoint to the required endpoint in the target node type. Since tosca.capabilities.Endpoint and tosca.relationships.ConnectsTo are TOSCA types, they can be used in templates and extended by subclassing in the usual ways, thus allowing the expression of additional semantics as needed.
The following diagram shows how the TOSCA node, capability and relationship
types enable modeling the application layer decoupled from the network model
intersecting at the Compute node using the Bindable capability type.
As you can see, the Port node type effectively acts a broker node between the Network node description and a host Compute node of an application.
This section describes how TOSCA supports the typical client/server and group communication semantics found in application architectures.
The tosca.relationships.ConnectsTo expresses that requirement that a source application component needs to be able to communicate with a target software component to consume the services of the target. ConnectTo is a component interdependency semantic in the most general sense and does not try imply how the communication between the source and target components is physically realized.
Application component intercommunication typically has conventions regarding which component(s) initiate the communication. Connection initiation semantics are specified in tosca.capabilities.Endpoint. Endpoints at each end of the tosca.relationships.ConnectsTo must indicate identical connection initiation semantics.
The following sections describe the normative connection initiation semantics for the tosca.relationships.ConnectsTo Relationship Type.
The Source to Target communication initiation semantic is the most common case where the source component initiates communication with the target component in order to fulfill an instance of the tosca.relationships.ConnectsTo relationship. The typical case is a “client” component connecting to a “server” component where the client initiates a stream oriented connection to a pre-defined transport specific port or set of ports.
It is the responsibility of the TOSCA implementation to ensure the source component has a suitable network path to the target component and that the ports specified in the respective tosca.capabilities.Endpoint are not blocked. The TOSCA implementation may only represent state of the tosca.relationships.ConnectsTo relationship as fulfilled after the actual network communication is enabled and the source and target components are in their operational states.
Note that the connection initiation semantic only impacts the fulfillment of the actual connectivity and does not impact the node traversal order implied by the tosca.relationships.ConnectsTo Relationship Type.
The Target to Source communication initiation semantic is a less common case where the target component initiates communication with the source comment in order to fulfill an instance of the tosca.relationships.ConnectsTo relationship. This “reverse” connection initiation direction is typically required due to some technical requirements of the components or protocols involved, such as the requirement that SSH mush only be initiated from target component in order to fulfill the services required by the source component.
It is the responsibility of the TOSCA implementation to ensure the source component has a suitable network path to the target component and that the ports specified in the respective tosca.capabilities.Endpoint are not blocked. The TOSCA implementation may only represent state of the tosca.relationships.ConnectsTo relationship as fulfilled after the actual network communication is enabled and the source and target components are in their operational states.
Note that the connection initiation semantic only impacts the fulfillment of the actual connectivity and does not impact the node traversal order implied by the tosca.relationships.ConnectsTo Relationship Type.
The Peer-to-Peer communication initiation semantic allows any member of a group to initiate communication with any other member of the same group at any time. This semantic typically appears in clustering and distributed services where there is redundancy of components or services.
It is the responsibility of the TOSCA implementation to ensure the source component has a suitable network path between all the member component instances and that the ports specified in the respective tosca.capabilities.Endpoint are not blocked, and the appropriate multicast communication, if necessary, enabled. The TOSCA implementation may only represent state of the tosca.relationships.ConnectsTo relationship as fulfilled after the actual network communication is enabled such that at least one-member component of the group may reach any other member component of the group.
Endpoints specifying the Peer-to-Peer initiation semantic need not be related with a tosca.relationships.ConnectsTo relationship for the common case where the same set of component instances must communicate with each other.
Note that the connection initiation semantic only impacts the fulfillment of the actual connectivity and does not impact the node traversal order implied by the tosca.relationships.ConnectsTo Relationship Type.
TOSCA Service Templates must express enough details about application component intercommunication to enable TOSCA implementations to fulfill these communication semantics in the network infrastructure. TOSCA currently focuses on TCP/IP as this is the most pervasive in today’s cloud infrastructures. The layer 4 ports required for application component intercommunication are specified in tosca.capabilities.Endpoint. The union of the port specifications of both the source and target tosca.capabilities.Endpoint which are part of the tosca.relationships.ConnectsTo Relationship Template are interpreted as the effective set of ports which must be allowed in the network communication.
The meaning of Source and Target port(s) corresponds to the direction of the respective tosca.relationships.ConnectsTo.
TOSCA orchestrators are responsible for the provisioning of the network connectivity for declarative TOSCA Service Templates (Declarative TOSCA Service Templates don’t contain explicit plans). This means that the TOSCA orchestrator must be able to infer a suitable logical connectivity model from the Service Template and then decide how to provision the logical connectivity, referred to as “fulfillment”, on the available underlying infrastructure. In order to enable fulfillment, sufficient technical details still must be specified, such as the required protocols, ports and QOS information. TOSCA connectivity types, such as tosca.capabilities.Endpoint, provide well defined means to express these details.
TOSCA Service Templates are by default network agnostic. TOSCA’s application centric approach only requires that a TOSCA Service Template contain enough information for a TOSCA orchestrator to infer suitable network connectivity to meet the needs of the application components. Thus Service Template designers are not required to be aware of or provide specific requirements for underlying networks. This approach yields the most portable Service Templates, allowing them to be deployed into any infrastructure which can provide the necessary component interconnectivity.
TOSCA provides mechanisms for providing control over network fulfillment.
This mechanism allows the application network designer to express in service template or network template how the networks should be provisioned.
For the use cases described below let’s assume we have a typical 3-tier application which is consisting of FE (frontend), BE (backend) and DB (database) tiers. The simple application topology diagram can be shown below:
Figure‑5: Typical 3-Tier Network
When deploying an application in service provider’s on-premise cloud, it’s very common that one or more of the application’s services should be accessible from an ad-hoc OAM (Operations, Administration and Management) network which exists in the service provider backbone.
As an application network designer, I’d like to express in my TOSCA network template (which corresponds to my TOSCA service template) the network CIDR block, start ip, end ip and segmentation ID (e.g. VLAN id).
The diagram below depicts a typical 3-tiers application with specific networking requirements for its FE tier server cluster:
The diagram below defines a set of networking requirements for the backend and DB tiers of the 3-tier app mentioned above.
The same 3-tier app requires for its admin traffic network to manage the IP allocation by its own DHCP which runs autonomously as part of application domain.
For this purpose, the app network designer would like to express in TOSCA that the underlying provisioned network will be set with DHCP_ENABLED=false. See this illustrated in the figure below:
The TOSCA Network node represents a simple, logical network service.
|
Shorthand Name |
Network |
|
Type Qualified Name |
tosca:Network |
|
Type URI |
tosca.nodes.network.Network |
|
Name |
Required |
Type |
Constraints |
Description |
|
ip_version |
no |
valid_values: [4, 6] default: 4 |
The IP version of the requested network |
|
|
cidr |
no |
None |
The cidr block of the requested network |
|
|
start_ip |
no |
None |
The IP address to be used as the 1st one in a pool of addresses derived from the cidr block full IP range |
|
|
end_ip |
no |
None |
The IP address to be used as the last one in a pool of addresses derived from the cidr block full IP range |
|
|
gateway_ip |
no |
None |
The gateway IP address. |
|
|
network_name |
no |
None |
An Identifier that represents an existing Network instance in the underlying cloud infrastructure – OR – be used as the name of the new created network. · If network_name is provided along with network_id they will be used to uniquely identify an existing network and not creating a new one, means all other possible properties are not allowed. · network_name should be more convenient for using. But in case that network name uniqueness is not guaranteed then one should provide a network_id as well. |
|
|
network_id |
no |
None |
An Identifier that represents an existing Network instance in the underlying cloud infrastructure. This property is mutually exclusive with all other properties except network_name. · Appearance of network_id in network template instructs the Tosca container to use an existing network instead of creating a new one. · network_name should be more convenient for using. But in case that network name uniqueness is not guaranteed then one should add a network_id as well. · network_name and network_id can be still used together to achieve both uniqueness and convenient. |
|
|
segmentation_id |
no |
None |
A segmentation identifier in the underlying cloud infrastructure (e.g., VLAN id, GRE tunnel id). If the segmentation_id is specified, the network_type or physical_network properties should be provided as well. |
|
|
network_type |
no |
None |
Optionally, specifies the nature of the physical network in the underlying cloud infrastructure. Examples are flat, vlan, gre or vxlan. For flat and vlan types, physical_network should be provided too. |
|
|
physical_network |
no |
None |
Optionally, identifies the physical network on top of which the network is implemented, e.g. physnet1. This property is required if network_type is flat or vlan. |
|
|
dhcp_enabled |
no |
default: true |
Indicates the TOSCA container to create a virtual network instance with or without a DHCP service. |
|
Name |
Required |
Type |
Constraints |
Description |
|
segmentation_id |
no |
None |
The actual segmentation_id that is been assigned to the network by the underlying cloud infrastructure. |
|
tosca.nodes.network.Network: derived_from: tosca.nodes.Root properties: ip_version: type: integer required: false default: 4 constraints: - valid_values: [ 4, 6 ] cidr: type: string required: false start_ip: type: string required: false end_ip: type: string required: false gateway_ip: type: string required: false network_name: type: string required: false network_id: type: string required: false segmentation_id: type: string required: false network_type: type: string required: false physical_network: type: string required: false capabilities: link: |
The TOSCA Port node represents a logical entity that associates between Compute and Network normative types.
The Port node type effectively represents a single virtual NIC on the Compute node instance.
|
Shorthand Name |
Port |
|
Type Qualified Name |
tosca:Port |
|
Type URI |
tosca.nodes.network.Port |
|
Name |
Required |
Type |
Constraints |
Description |
|
ip_address |
no |
None |
Allow the user to set a fixed IP address.
Note that this address is a request to the provider which they will attempt to fulfill but may not be able to dependent on the network the port is associated with. |
|
|
order |
no |
greater_or_equal: 0 default: 0 |
The order of the NIC on the compute instance (e.g. eth2).
Note: when binding more than one port to a single compute (aka multi vNICs) and ordering is desired, it is *mandatory* that all ports will be set with an order value and. The order values must represent a positive, arithmetic progression that starts with 0 (e.g. 0, 1, 2, …, n). |
|
|
is_default |
no |
default: false |
Set is_default=true to apply a default gateway route on the running compute instance to the associated network gateway.
Only one port that is associated to single compute node can set as default=true. |
|
|
ip_range_start |
no |
None |
Defines the starting IP of a range to be allocated for the compute instances that are associated by this Port. Without setting this property the IP allocation is done from the entire CIDR block of the network. |
|
|
ip_range_end |
no |
None |
Defines the ending IP of a range to be allocated for the compute instances that are associated by this Port. Without setting this property the IP allocation is done from the entire CIDR block of the network. |
|
Name |
Required |
Type |
Constraints |
Description |
|
ip_address |
no |
None |
The IP address would be assigned to the associated compute instance. |
|
tosca.nodes.network.Port: derived_from: tosca.nodes.Root properties: ip_address: type: string required: false order: type: integer required: true default: 0 constraints: - greater_or_equal: 0 is_default: type: boolean required: false default: false ip_range_start: type: string required: false ip_range_end: type: string required: false requirements: - link: capability: tosca.capabilities.network.Linkable relationship: tosca.relationships.network.LinksTo - binding: capability: tosca.capabilities.network.Bindable relationship: tosca.relationships.network.BindsTo |
A node type that includes the Linkable capability indicates that it can be pointed to by a tosca.relationships.network.LinksTo relationship type.
|
Shorthand Name |
Linkable |
|
Type Qualified Name |
tosca:.Linkable |
|
Type URI |
tosca.capabilities.network.Linkable |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.capabilities.network.Linkable: derived_from: tosca.capabilities.Node |
This relationship type represents an association relationship between Port and Network node types.
|
Shorthand Name |
LinksTo |
|
Type Qualified Name |
tosca:LinksTo |
|
Type URI |
tosca.relationships.network.LinksTo |
|
tosca.relationships.network.LinksTo: derived_from: tosca.relationships.DependsOn valid_target_types: [ tosca.capabilities.network.Linkable ] |
This type represents a network association relationship between Port and Compute node types.
|
Shorthand Name |
network.BindsTo |
|
Type Qualified Name |
tosca:BindsTo |
|
Type URI |
tosca.relationships.network.BindsTo |
|
tosca.relationships.network.BindsTo: derived_from: tosca.relationships.DependsOn valid_target_types: [ tosca.capabilities.network.Bindable ] |
This approach allows someone who understands the application’s networking requirements, mapping the details of the underlying network to the appropriate node templates in the application.
The motivation for this approach is providing the application network designer a fine-grained control on how networks are provisioned and stitched to its application by the TOSCA orchestrator and underlying cloud infrastructure while still preserving the portability of his service template. Preserving the portability means here not doing any modification in service template but just “plug-in” the desired network modeling. The network modeling can reside in the same service template file but the best practice should be placing it in a separated self-contained network template file.
This “pluggable” network template approach introduces a new normative node type called Port, capability called tosca.capabilities.network.Linkable and relationship type called tosca.relationships.network.LinksTo.
The idea of the Port is to elegantly associate the desired compute nodes with the desired network nodes while not “touching” the compute itself.
The following diagram series demonstrate the plug-ability strength of this approach.
Let’s assume an application designer has modeled a service template as shown in Figure 1 that describes the application topology nodes (compute, storage, software components, etc.) with their relationships. The designer ideally wants to preserve this service template and use it in any cloud provider environment without any change.
Figure‑6: Generic Service Template
When the application designer comes to consider its application networking requirement they typically call the network architect/designer from their company (who has the correct expertise).
The network designer, after understanding the application connectivity requirements and optionally the target cloud provider environment, is able to model the network template and plug it to the service template as shown in Figure 2:
Figure‑7: Service template with network template A
When there’s a new target cloud environment to run the application on, the network designer is simply creates a new network template B that corresponds to the new environmental conditions and provide it to the application designer which packs it into the application CSAR.
Figure‑8: Service template with network template B
The node templates for these three networks would be defined as follows:
|
node_templates: frontend: type: tosca.nodes.Compute properties: # omitted for brevity
backend: type: tosca.nodes.Compute properties: # omitted for brevity
database: type: tosca.nodes.Compute properties: # omitted for brevity
oam_network: type: tosca.nodes.network.Network properties: # omitted for brevity
admin_network: type: tosca.nodes.network.Network properties: # omitted for brevity
data_network: type: tosca.nodes.network.Network properties: # omitted for brevity
# ports definition fe_oam_net_port: type: tosca.nodes.network.Port properties: is_default: true ip_range_start: { get_input: fe_oam_net_ip_range_start } ip_range_end: { get_input: fe_oam_net_ip_range_end } requirements: - link: oam_network - binding: frontend
fe_admin_net_port: type: tosca.nodes.network.Port requirements: - link: admin_network - binding: frontend
be_admin_net_port: type: tosca.nodes.network.Port properties: order: 0 requirements: - link: admin_network - binding: backend
be_data_net_port: type: tosca.nodes.network.Port properties: order: 1 requirements: - link: data_network - binding: backend
db_data_net_port: type: tosca.nodes.network.Port requirements: - link: data_network - binding: database
|
This approach allows the Service Template designer to map an endpoint to a logical network.
The use case shown below examines a way to express in the TOSCA YAML service template a typical 3-tier application with their required networking modeling:
|
node_templates: frontend: type: tosca.nodes.Compute properties: # omitted for brevity requirements: - network_oam: oam_network - network_admin: admin_network backend: type: tosca.nodes.Compute properties: # omitted for brevity requirements: - network_admin: admin_network - network_data: data_network
database: type: tosca.nodes.Compute properties: # omitted for brevity requirements: - network_data: data_network
oam_network: type: tosca.nodes.network.Network properties: ip_version: { get_input: oam_network_ip_version } cidr: { get_input: oam_network_cidr } start_ip: { get_input: oam_network_start_ip } end_ip: { get_input: oam_network_end_ip }
admin_network: type: tosca.nodes.network.Network properties: ip_version: { get_input: admin_network_ip_version } dhcp_enabled: { get_input: admin_network_dhcp_enabled }
data_network: type: tosca.nodes.network.Network properties: ip_version: { get_input: data_network_ip_version } cidr: { get_input: data_network_cidr } |
This section defines non-normative types which are used only in examples and use cases in this specification and are included only for completeness for the reader. Implementations of this specification are not required to support these types for conformance.
This section contains are non-normative Artifact Types used in use cases and examples.
This artifact represents a Docker “image” (a TOSCA deployment artifact type) which is a binary comprised of one or more (a union of read-only and read-write) layers created from snapshots within the underlying Docker Union File System.
|
tosca.artifacts.Deployment.Image.Container.Docker: derived_from: tosca.artifacts.Deployment.Image description: Docker Container Image |
A Virtual Machine (VM) formatted as an ISO standard disk image.
|
tosca.artifacts.Deployment.Image.VM.ISO: derived_from: tosca.artifacts.Deployment.Image.VM description: Virtual Machine (VM) image in ISO disk format mime_type: application/octet-stream file_ext: [ iso ] |
A Virtual Machine (VM) formatted as a QEMU emulator version 2 standard disk image.
|
tosca.artifacts.Deployment.Image.VM.QCOW2: derived_from: tosca.artifacts.Deployment.Image.VM description: Virtual Machine (VM) image in QCOW v2 standard disk format mime_type: application/octet-stream file_ext: [ qcow2 ] |
This artifact type represents a template file written in Jinja2 templating language [Jinja2].
|
Shorthand Name |
Template.Jinja2 |
|
Type Qualified Name |
tosca:template.jinja2 |
|
Type URI |
tosca.artifacts.template.Jinja2 |
|
tosca.artifacts.template.Jinja2: derived_from: tosca.artifacts.template description: Jinja2 template file |
|
dbServer: type: tosca.nodes.Compute properties: name: description: artifacts: configuration: type: tosca.artifacts.Implementation.Ansible file: implementation/configuration/Ansible/configure.yml template_configuration: type: tosca.artifacts.template.Jinja2 file: implementation/configuration/templates/template_configuration.jinja2 interfaces: Standard: configure: inputs: input1: . . . implementation: primary: configuration dependencies: [ template_configuration ] |
This artifact type represents a template file written in Twig templating language [Twig].
|
Shorthand Name |
Template.Twig |
|
Type Qualified Name |
tosca:template.Twig |
|
Type URI |
tosca.artifacts.template.Twig |
|
tosca.artifacts.template.Twig: derived_from: tosca.artifacts.template description: Twig template file |
This section contains are non-normative Capability Types used in use cases and examples.
The type indicates capabilities of a Docker runtime environment (client).
|
Shorthand Name |
Container.Docker |
|
Type Qualified Name |
tosca:Container.Docker |
|
Type URI |
tosca.capabilities.Container.Docker |
|
Name |
Required |
Type |
Constraints |
Description |
|
version |
no |
version[] |
None |
The Docker version capability (i.e., the versions supported by the capability). |
|
publish_all |
no |
default: false |
Indicates that all ports (ranges) listed in the dockerfile using the EXPOSE keyword be published. |
|
|
publish_ports |
no |
list of PortSpec |
None |
List of ports mappings from source (Docker container) to target (host) ports to publish. |
|
expose_ports |
no |
list of PortSpec |
None |
List of ports mappings from source (Docker container) to expose to other Docker containers (not accessible outside host). |
|
volumes |
no |
list of string |
None |
The dockerfile VOLUME command which is used to enable access from the Docker container to a directory on the host machine. |
|
host_id |
no |
None |
The optional identifier of an existing host resource that should be used to run this container on. |
|
|
volume_id |
no |
None |
The optional identifier of an existing storage volume (resource) that should be used to create the container’s mount point(s) on. |
|
tosca.capabilities.Container.Docker: derived_from: tosca.capabilities.Container properties: version: type: list required: false entry_schema: version publish_all: type: boolean default: false required: false publish_ports: type: list entry_schema: PortSpec required: false expose_ports: type: list entry_schema: PortSpec required: false volumes: type: list entry_schema: string required: false |
· When the expose_ports property is used, only the source and source_range properties of PortSpec would be valid for supplying port numbers or ranges, the target and target_range properties would be ignored.
This section contains non-normative node types referenced in use cases and examples. All additional Attributes, Properties, Requirements and Capabilities shown in their definitions (and are not inherited from ancestor normative types) are also considered to be non-normative.
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.nodes.Database.MySQL: derived_from: tosca.nodes.Database requirements: - host: node: tosca.nodes.DBMS.MySQL |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.nodes.DBMS.MySQL: derived_from: tosca.nodes.DBMS properties: port: description: reflect the default MySQL server port default: 3306 root_password: # MySQL requires a root_password for configuration # Override parent DBMS definition to make this property required required: true capabilities: # Further constrain the ‘host’ capability to only allow MySQL databases host: valid_source_types: [ tosca.nodes.Database.MySQL ] |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.nodes.WebServer.Apache: derived_from: tosca.nodes.WebServer |
This section defines a non-normative Node type for the WordPress [WordPress] application.
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.nodes.WebApplication.WordPress: derived_from: tosca.nodes.WebApplication properties: admin_user: type: string admin_password: type: string db_host: type: string requirements: - database_endpoint: capability: tosca.capabilities.Endpoint.Database node: tosca.nodes.Database relationship: tosca.relationships.ConnectsTo |
This non-normative node type represents a Node.js [NodeJS] web application server.
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.nodes.WebServer.Nodejs: derived_from: tosca.nodes.WebServer properties: # Property to supply the desired implementation in the Github repository github_url: required: no type: string description: location of the application on the github. default: https://github.com/mmm/testnode.git interfaces: Standard: inputs: github_url: type: string |
|
Name |
Required |
Type |
Constraints |
Description |
|
N/A |
N/A |
N/A |
N/A |
N/A |
|
tosca.nodes.Container.Application.Docker: derived_from: tosca.nodes.Containertosca.nodes.Container.Application requirements: - host: capability: tosca.capabilities.Container.Docker |
This section is non-normative and includes use cases that explore how to model components and their relationships using TOSCA Simple Profile in YAML.
This use case examines the ways TOSCA YAML can be used to express a simple hosting relationship (i.e., HostedOn) using the normative TOSCA WebServer and WebApplication node types defined in this specification.
For convenience, relevant parts of the normative TOSCA Node Type for WebServer are shown below:
|
tosca.nodes.WebServer derived_from: SoftwareComponent capabilities: ... host: type: tosca.capabilities.Container valid_source_types: [ tosca.nodes.WebApplication ] |
As can be seen, the WebServer Node Type declares its capability to “contain” (i.e., host) other nodes using the symbolic name “host” and providing the Capability Type tosca.capabilities.Container. It should be noted that the symbolic name of “host” is not a reserved word, but one assigned by the type designer that implies at or betokens the associated capability. The Container capability definition also includes a required list of valid Node Types that can be contained by this, the WebServer, Node Type. This list is declared using the keyname of valid_source_types and in this case it includes only allowed type WebApplication.
The WebApplication node type needs to be able to describe the type of capability a target node would have to provide in order to “host” it. The normative TOSCA capability type tosca.capabilities.Container is used to describe all normative TOSCA hosting (i.e., container-containee pattern) relationships. As can be seen below, the WebApplication accomplishes this by declaring a requirement with the symbolic name “host” with the capability keyname set to tosca.capabilities.Container.
Again, for convenience, the relevant parts of the normative WebApplication Node Type are shown below:
|
tosca.nodes.WebApplication: derived_from: tosca.nodes.Root requirements: - host: capability: tosca.capabilities.Container node: tosca.nodes.WebServer relationship: tosca.relationships.HostedOn |
· The symbolic name “host” is not a keyword and was selected for consistent use in TOSCA normative node types to give the reader an indication of the type of requirement being referenced. A valid HostedOn relationship could still be established between WebApplicaton and WebServer in a TOSCA Service Template regardless of the symbolic name assigned to either the requirement or capability declaration.
This use case examines the ways TOSCA YAML can be used to express a simple connection relationship (i.e., ConnectsTo) between some service derived from the SoftwareComponent Node Type, to the normative WebServer node type defined in this specification.
The service template that would establish a ConnectsTo relationship as follows:
|
node_types: MyServiceType: derived_from: SoftwareComponent requirements: # This type of service requires a connection to a WebServer’s data_endpoint - connection1: node: WebServer relationship: ConnectsTo capability: Endpoint
topology_template: node_templates: my_web_service: type: MyServiceType ... requirements: - connection1: node: my_web_server
my_web_server: # Note, the normative WebServer node type declares the “data_endpoint” # capability of type tosca.capabilities.Endpoint. type: WebServer |
Since the normative WebServer Node Type only declares one capability of type tosca.capabilties.Endpoint (or Endpoint, its shortname alias in TOSCA) using the symbolic name data_endpoint, the my_web_service node template does not need to declare that symbolic name on its requirement declaration. If however, the my_web_server node was based upon some other node type that declared more than one capability of type Endpoint, then the capability keyname could be used to supply the desired symbolic name if necessary.
It should be noted that the best practice for designing Node Types in TOSCA should not export two capabilities of the same type if they truly offer different functionality (i.e., different capabilities) which should be distinguished using different Capability Type definitions.
This use case examines the ways TOSCA YAML can be used to express a simple AttachesTo relationship between a Compute node and a locally attached BlockStorage node.
The service template that would establish an AttachesTo relationship follows:
|
node_templates: my_server: type: Compute ... requirements: # contextually this can only be a relationship type - local_storage: # capability is provided by Compute Node Type node: my_block_storage relationship: type: AttachesTo properties: location: /path1/path2 # This maps the local requirement name ‘local_storage’ to the # target node’s capability name ‘attachment’
my_block_storage: type: BlockStorage properties: size: 10 GB |
This builds upon the previous use case (10.1.3) to examine how a template author could attach multiple Compute nodes (templates) to the same BlockStorage node (template), but with slightly different property values for the AttachesTo relationship.
Specifically, several notation options are shown (in this use case) that achieve the same desired result.
Referencing an explicitly declared Relationship Template is a convenience of the Simple Profile that allows template authors an entity to set, constrain or override the properties and operations as defined in its declared (Relationship) Type much as allowed now for Node Templates. It is especially useful when a complex Relationship Type (with many configurable properties or operations) has several logical occurrences in the same Service (Topology) Template; allowing the author to avoid configuring these same properties and operations in multiple Node Templates.
This notation extends the methodology used for establishing a HostedOn relationship, but allowing template author to supply (dynamic) configuration and/or override of properties and operations.
Note: This option will remain valid for Simple Profile regardless of other notation (copy or aliasing) options being discussed or adopted for future versions.
|
node_templates:
my_block_storage: type: BlockStorage properties: size: 10
my_web_app_tier_1: type: Compute requirements: - local_storage: node: my_block_storage relationship: MyAttachesTo # use default property settings in the Relationship Type definition
my_web_app_tier_2: type: Compute requirements: - local_storage: node: my_block_storage relationship: type: MyAttachesTo # Override default property setting for just the ‘location’ property properties: location: /some_other_data_location
relationship_types:
MyAttachesTo: derived_from: AttachesTo properties: location: /default_location interfaces: Configure: post_configure_target: implementation: default_script.sh |
This option shows how to explicitly declare different named Relationship Templates within the Service Template as part of a relationship_templates section (which have different property values) and can be referenced by different Compute typed Node Templates.
|
node_templates:
my_block_storage: type: BlockStorage properties: size: 10
my_web_app_tier_1: derived_from: Compute requirements: - local_storage: node: my_block_storage relationship: storage_attachesto_1
my_web_app_tier_2: derived_from: Compute requirements: - local_storage: node: my_block_storage relationship: storage_attachesto_2
relationship_templates: storage_attachesto_1: type: MyAttachesTo properties: location: /my_data_location
storage_attachesto_2: type: MyAttachesTo properties: location: /some_other_data_location
relationship_types:
MyAttachesTo: derived_from: AttachesTo interfaces: some_interface_name: some_operation: implementation: default_script.sh |
How does TOSCA make it easier to create a new relationship template that is mostly the same as one that exists without manually copying all the same information? TOSCA provides the copy keyname as a convenient way to copy an existing template definition into a new template definition as a starting point or basis for describing a new definition and avoid manual copy. The end results are cleaner TOSCA Service Templates that allows the description of only the changes (or deltas) between similar templates.
The example below shows that the Relationship Template named storage_attachesto_1 provides some overrides (conceptually a large set of overrides) on its Type which the Relationship Template named storage_attachesto_2 wants to “copy” before perhaps providing a smaller number of overrides.
|
node_templates:
my_block_storage: type: BlockStorage properties: size: 10
my_web_app_tier_1: derived_from: Compute requirements: - attachment: node: my_block_storage relationship: storage_attachesto_1
my_web_app_tier_2: derived_from: Compute requirements: - attachment: node: my_block_storage relationship: storage_attachesto_2
relationship_templates: storage_attachesto_1: type: MyAttachesTo properties: location: /my_data_location interfaces: some_interface_name: some_operation_name_1: my_script_1.sh some_operation_name_2: my_script_2.sh some_operation_name_3: my_script_3.sh
storage_attachesto_2: # Copy the contents of the “storage_attachesto_1” template into this new one copy: storage_attachesto_1 # Then change just the value of the location property properties: location: /some_other_data_location
relationship_types:
MyAttachesTo: derived_from: AttachesTo interfaces: some_interface_name: some_operation: implementation: default_script.sh |
This section is non-normative and includes use cases that show how to model Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and complete application uses cases using TOSCA Simple Profile in YAML.
Many of the use cases listed below can be found under the following link:
https://github.com/openstack/heat-translator/tree/master/translator/tests/data
|
Name |
Description |
|
Compute: Create a single Compute instance with a host Operating System |
Introduces a TOSCA Compute node type which is used to stand up a single compute instance with a host Operating System Virtual Machine (VM) image selected by the platform provider using the Compute node’s properties. |
|
Software Component 1: Automatic deployment of a Virtual Machine (VM) image artifact |
Introduces the SoftwareComponent node type which declares software that is hosted on a Compute instance. In this case, the SoftwareComponent declares a VM image as a deployment artifact which includes its own pre-packaged operating system and software. The TOSCA Orchestrator detects this known deployment artifact type on the SoftwareComponent node template and automatically deploys it to the Compute node. |
|
BlockStorage-1: Attaching Block Storage to a single Compute instance |
Demonstrates how to attach a TOSCA BlockStorage node to a Compute node using the normative AttachesTo relationship. |
|
BlockStorage-2: Attaching Block Storage using a custom Relationship Type |
Demonstrates how to attach a TOSCA BlockStorage node to a Compute node using a custom RelationshipType that derives from the normative AttachesTo relationship. |
|
BlockStorage-3: Using a Relationship Template of type AttachesTo |
Demonstrates how to attach a TOSCA BlockStorage node to a Compute node using a TOSCA Relationship Template that is based upon the normative AttachesTo Relationship Type. |
|
BlockStorage-4: Single Block Storage shared by 2-Tier Application with custom AttachesTo Type and implied relationships |
This use case shows 2 Compute instances (2 tiers) with one BlockStorage node, and also uses a custom AttachesTo Relationship that provides a default mount point (i.e., location) which the 1st tier uses, but the 2nd tier provides a different mount point. |
|
BlockStorage-5: Single Block Storage shared by 2-Tier Application with custom AttachesTo Type and explicit Relationship Templates |
This use case is like the previous BlockStorage-4 use case, but also creates two relationship templates (one for each tier) each of which provide a different mount point (i.e., location) which overrides the default location defined in the custom Relationship Type. |
|
BlockStorage-6: Multiple Block Storage attached to different Servers |
This use case demonstrates how two different TOSCA BlockStorage nodes can be attached to two different Compute nodes (i.e., servers) each using the normative AttachesTo relationship. |
|
Object Storage 1: Creating an Object Storage service |
Introduces the TOSCA ObjectStorage node type and shows how it can be instantiated. |
|
Network-1: Server bound to a new network |
Introduces the TOSCA Network and Port nodes used for modeling logical networks using the LinksTo and BindsTo Relationship Types. In this use case, the template is invoked without an existing network_name as an input property so a new network is created using the properties declared in the Network node. |
|
Network-2: Server bound to an existing network |
Shows how to use a network_name as an input parameter to the template to allow a server to be associated with (i.e. bound to) an existing Network. |
|
Network-3: Two servers bound to a single network |
This use case shows how two servers (Compute nodes) can be associated with the same Network node using two logical network Ports. |
|
Network-4: Server bound to three networks |
This use case shows how three logical networks (Network nodes), each with its own IP address range, can be associated with the same server (Compute node). |
|
WebServer-DBMS-1: WordPress [WordPress] + MySQL, single instance |
Shows how to host a TOSCA WebServer with a TOSCA WebApplication, DBMS and Database Node Types along with their dependent HostedOn and ConnectsTo relationships. |
|
WebServer-DBMS-2: Nodejs with PayPal Sample App and MongoDB on separate instances |
Instantiates a 2-tier application with Nodejs and its (PayPal sample) WebApplication on one tier which connects a MongoDB database (which stores its application data) using a ConnectsTo relationship. |
|
Multi-Tier-1: Elasticsearch, Logstash, Kibana (ELK) |
Shows Elasticsearch, Logstash and Kibana (ELK) being used in a typical manner to collect, search and monitor/visualize data from a running application.
This use case builds upon the previous Nodejs/MongoDB 2-tier application as the one being monitored. The collectd and rsyslog components are added to both the WebServer and Database tiers which work to collect data for Logstash.
In addition to the application tiers, a 3rd tier is introduced with Logstash to collect data from the application tiers. Finally a 4th tier is added to search the Logstash data with Elasticsearch and visualize it using Kibana.
Note: This use case also shows the convenience of using a single YAML macro (declared in the dsl_definitions section of the TOSCA Service Template) on multiple Compute nodes. |
|
Container-1: Containers using Docker single Compute instance (Containers only) |
Minimalist TOSCA Service Template description of 2 Docker containers linked to each other. Specifically, one container runs wordpress and connects to second mysql database container both on a single server (i.e., Compute instance). The use case also demonstrates how TOSCA declares and references Docker images from the Docker Hub repository.
Variation 1: Docker Container nodes (only) providing their Docker Requirements allowing platform (orchestrator) to select/provide the underlying Docker implementation (Capability). |
|
Artifacts: Compute Node with multiple artifacts |
Illustrates how multiple artifacts for different lifecycle operations (create, terminate, configure, etc.) can be associated with a node. |
This use case demonstrates how the TOSCA Simple Profile specification can be used to stand up a single Compute instance with a guest Operating System using a normative TOSCA Compute node. The TOSCA Compute node is declarative in that the service template describes both the processor and host operating system platform characteristics (i.e., properties declared on the capability named “os” sometimes called a “flavor”) that are desired by the template author. The cloud provider would attempt to fulfill these properties (to the best of its abilities) during orchestration.
This use case introduces the following TOSCA Simple Profile features:
· A node template that uses the normative TOSCA Compute Node Type along with showing an exemplary set of its properties being configured.
· Use of the TOSCA Service Template inputs section to declare a configurable value the template user may supply at runtime. In this case, the “host” property named “num_cpus” (of type integer) is declared.
o Use of a property constraint to limit the allowed integer values for the “num_cpus” property to a specific list supplied in the property declaration.
· Use of the TOSCA Service Template outputs section to declare a value the template user may request at runtime. In this case, the property named “instance_ip” is declared
o The “instance_ip” output property is programmatically retrieved from the Compute node’s “public_address” attribute using the TOSCA Service Template-level get_attribute function.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile that just defines a single compute instance and selects a (guest) host Operating System from the Compute node’s properties. Note, this example does not include default values on inputs properties.
topology_template: inputs: cpus: type: integer description: Number of CPUs for the server. constraints: - valid_values: [ 1, 2, 4, 8 ]
node_templates: my_server: type: Compute capabilities: host: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 1 GB os: properties: architecture: x86_64 type: Linux distribution: ubuntu version: 12.04 outputs: private_ip: description: The private IP address of the deployed server instance. value: { get_attribute: [my_server, private_address] } |
· This use case uses a versioned, Linux Ubuntu distribution on the Compute node.
This use case demonstrates how the TOSCA SoftwareComponent node type can be used to declare software that is packaged in a standard Virtual Machine (VM) image file format (i.e., in this case QCOW2) and is hosted on a TOSCA Compute node (instance). In this variation, the SoftwareComponent declares a VM image as a deployment artifact that includes its own pre-packaged operating system and software. The TOSCA Orchestrator detects this known deployment artifact type on the SoftwareComponent node template and automatically deploys it to the Compute node.
This use case introduces the following TOSCA Simple Profile features:
· A node template that uses the normative TOSCA SoftwareComponent Node Type along with showing an exemplary set of its properties being configured.
· Use of the TOSCA Service Template artifacts section to declare a Virtual Machine (VM) image artifact type which is referenced by the SoftwareComponent node template.
· The VM file format, in this case QCOW2, includes its own guest Operating System (OS) and therefore does not “require” a TOSCA OperatingSystem capability from the TOSCA Compute node.
This use case assumes the following:
· That the TOSCA Orchestrator (working with the Cloud provider’s underlying management services) is able to instantiate a Compute node that has a hypervisor that supports the Virtual Machine (VM) image format, in this case QCOW2, which should be compatible with many standard hypervisors such as XEN and KVM.
· This is not a “bare metal” use case and assumes the existence of a hypervisor on the machine that is allocated to “host” the Compute instance supports (e.g. has drivers, etc.) the VM image format in this example.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA Simple Profile with a SoftwareComponent node with a declared Virtual machine (VM) deployment artifact that automatically deploys to its host Compute node.
topology_template:
node_templates: my_virtual_machine: type: SoftwareComponent artifacts: my_vm_image: file: images/fedora-18-x86_64.qcow2 type: tosca.artifacts.Deployment.Image.VM.QCOW2 topology: my_VMs_topology.yaml requirements: - host: my_server # Automatically deploy the VM image referenced on the create operation interfaces: Standard: create: my_vm_image
# Compute instance with no Operating System guest host my_server: type: Compute capabilities: # Note: no guest OperatingSystem requirements as these are in the image. host: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 4 GB
outputs: private_ip: description: The private IP address of the deployed server instance. value: { get_attribute: [my_server, private_address] } |
· The use of the type keyname on the artifact definition (within the my_virtual_machine node template) to declare the ISO image deployment artifact type (i.e., tosca.artifacts.Deployment.Image.VM.ISO) is redundant since the file extension is “.iso” which associated with this known, declared artifact type.
· This use case references a filename on the my_vm_image artifact, which indicates a Linux, Fedora 18, x86 VM image, only as one possible example.
This use case demonstrates how to attach a TOSCA BlockStorage node to a Compute node using the normative AttachesTo relationship.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with server and attached block storage using the normative AttachesTo Relationship Type.
topology_template:
inputs: cpus: type: integer description: Number of CPUs for the server. constraints: - valid_values: [ 1, 2, 4, 8 ] storage_size: type: scalar-unit.size description: Size of the storage to be created. default: 1 GB storage_snapshot_id: type: string description: > Optional identifier for an existing snapshot to use when creating storage. storage_location: type: string description: Block storage mount point (filesystem path).
node_templates: my_server: type: Compute capabilities: host: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 1 GB os: properties: architecture: x86_64 type: linux distribution: fedora version: 18.0 requirements: - local_storage: node: my_storage relationship: type: AttachesTo properties: location: { get_input: storage_location }
my_storage: type: BlockStorage properties: size: { get_input: storage_size } snapshot_id: { get_input: storage_snapshot_id }
outputs: private_ip: description: The private IP address of the newly created compute instance. value: { get_attribute: [my_server, private_address] } volume_id: description: The volume id of the block storage instance. value: { get_attribute: [my_storage, volume_id] } |
This use case demonstrates how to attach a TOSCA BlockStorage node to a Compute node using a custom RelationshipType that derives from the normative AttachesTo relationship.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with server and attached block storage using a custom AttachesTo Relationship Type.
relationship_types: MyCustomAttachesTo: derived_from: AttachesTo
topology_template: inputs: cpus: type: integer description: Number of CPUs for the server. constraints: - valid_values: [ 1, 2, 4, 8 ] storage_size: type: scalar-unit.size description: Size of the storage to be created. default: 1 GB storage_snapshot_id: type: string description: > Optional identifier for an existing snapshot to use when creating storage. storage_location: type: string description: Block storage mount point (filesystem path).
node_templates: my_server: type: Compute capabilities: host: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 4 GB os: properties: architecture: x86_64 type: Linux distribution: Fedora version: 18.0 requirements: - local_storage: node: my_storage # Declare custom AttachesTo type using the ‘relationship’ keyword relationship: type: MyCustomAttachesTo properties: location: { get_input: storage_location } my_storage: type: BlockStorage properties: size: { get_input: storage_size } snapshot_id: { get_input: storage_snapshot_id }
outputs: private_ip: description: The private IP address of the newly created compute instance. value: { get_attribute: [my_server, private_address] } volume_id: description: The volume id of the block storage instance. value: { get_attribute: [my_storage, volume_id] } |
This use case demonstrates how to attach a TOSCA BlockStorage node to a Compute node using a TOSCA Relationship Template that is based upon the normative AttachesTo Relationship Type.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with server and attached block storage using a named Relationship Template for the storage attachment.
topology_template: inputs: cpus: type: integer description: Number of CPUs for the server. constraints: - valid_values: [ 1, 2, 4, 8 ] storage_size: type: scalar-unit.size description: Size of the storage to be created. default: 1 GB storage_location: type: string description: Block storage mount point (filesystem path).
node_templates: my_server: type: Compute capabilities: host: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 4 GB os: properties: architecture: x86_64 type: Linux distribution: Fedora version: 18.0 requirements: - local_storage: node: my_storage # Declare template to use with ‘relationship’ keyword relationship: storage_attachment
my_storage: type: BlockStorage properties: size: { get_input: storage_size }
relationship_templates: storage_attachment: type: AttachesTo properties: location: { get_input: storage_location }
outputs: private_ip: description: The private IP address of the newly created compute instance. value: { get_attribute: [my_server, private_address] } volume_id: description: The volume id of the block storage instance. value: { get_attribute: [my_storage, volume_id] } |
This use case shows 2 compute instances (2 tiers) with one BlockStorage node, and also uses a custom AttachesTo Relationship that provides a default mount point (i.e., location) which the 1st tier uses, but the 2nd tier provides a different mount point.
Please note that this use case assumes both Compute nodes are accessing different directories within the shared, block storage node to avoid collisions.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with a Single Block Storage node shared by 2-Tier Application with custom AttachesTo Type and implied relationships.
relationship_types: MyAttachesTo: derived_from: tosca.relationships.AttachesTo properties: location: type: string default: /default_location
topology_template: inputs: cpus: type: integer description: Number of CPUs for the server. constraints: - valid_values: [ 1, 2, 4, 8 ] storage_size: type: scalar-unit.size default: 1 GB description: Size of the storage to be created. storage_snapshot_id: type: string description: > Optional identifier for an existing snapshot to use when creating storage.
node_templates: my_web_app_tier_1: type: tosca.nodes.Compute
capabilities: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 4096 MB os: properties: architecture: x86_64 type: Linux distribution: Fedora version: 18.0 requirements: - local_storage: node: my_storage relationship: MyAttachesTo
my_web_app_tier_2: type: tosca.nodes.Compute capabilities: host: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 4096 MB os: properties: architecture: x86_64 type: Linux distribution: Fedora version: 18.0 requirements: - local_storage: node: my_storage relationship: type: MyAttachesTo properties: location: /some_other_data_location
my_storage: type: tosca.nodes.Storage.BlockStoragetosca.nodes.Storage.BlockStorage properties: size: { get_input: storage_size } snapshot_id: { get_input: storage_snapshot_id }
outputs: private_ip_1: description: The private IP address of the application’s first tier. value: { get_attribute: [my_web_app_tier_1, private_address] } private_ip_2: description: The private IP address of the application’s second tier. value: { get_attribute: [my_web_app_tier_2, private_address] } volume_id: description: The volume id of the block storage instance. value: { get_attribute: [my_storage, volume_id] } |
This use case is like the Notation1 use case, but also creates two relationship templates (one for each tier) each of which provide a different mount point (i.e., location) which overrides the default location defined in the custom Relationship Type.
Please note that this use case assumes both Compute nodes are accessing different directories within the shared, block storage node to avoid collisions.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA
simple profile with a single Block
Storage node shared by 2-Tier Application with custom AttachesTo Type and
explicit Relationship Templates. relationship_types: MyAttachesTo: derived_from: tosca.relationships.AttachesTo properties: location: type: string default: /default_location
topology_template: inputs: cpus: type: integer description: Number of CPUs for the server. constraints: - valid_values: [ 1, 2, 4, 8 ] storage_size: type: scalar-unit.size default: 1 GB description: Size of the storage to be created. storage_snapshot_id: type: string description: > Optional identifier for an existing snapshot to use when creating storage. storage_location: type: string description: > Block storage mount point (filesystem path).
node_templates:
my_web_app_tier_1: type: tosca.nodes.Compute capabilities: host: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 4096 MB os: properties: architecture: x86_64 type: Linux distribution: Fedora version: 18.0 requirements: - local_storage: node: my_storage relationship: storage_attachesto_1
my_web_app_tier_2: type: tosca.nodes.Compute capabilities: host: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 4096 MB os: properties: architecture: x86_64 type: Linux distribution: Fedora version: 18.0 requirements: - local_storage: node: my_storage relationship: storage_attachesto_2
my_storage: type: tosca.nodes.Storage.BlockStorage properties: size: { get_input: storage_size } snapshot_id: { get_input: storage_snapshot_id }
relationship_templates: storage_attachesto_1: type: MyAttachesTo properties: location: /my_data_location
storage_attachesto_2: type: MyAttachesTo properties: location: /some_other_data_location outputs: private_ip_1: description: The private IP address of the application’s first tier. value: { get_attribute: [my_web_app_tier_1, private_address] } private_ip_2: description: The private IP address of the application’s second tier. value: { get_attribute: [my_web_app_tier_2, private_address] } volume_id: description: The volume id of the block storage instance. value: { get_attribute: [my_storage, volume_id] } |
This use case demonstrates how two different TOSCA BlockStorage nodes can be attached to two different Compute nodes (i.e., servers) each using the normative AttachesTo relationship.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with 2 servers each with different attached block storage.
topology_template: inputs: cpus: type: integer description: Number of CPUs for the server. constraints: - valid_values: [ 1, 2, 4, 8 ] storage_size: type: scalar-unit.size default: 1 GB description: Size of the storage to be created. storage_snapshot_id: type: string description: > Optional identifier for an existing snapshot to use when creating storage. storage_location: type: string description: > Block storage mount point (filesystem path).
node_templates: my_server: type: tosca.nodes.Compute capabilities: host: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 4096 MB os: properties: architecture: x86_64 type: Linux distribution: Fedora version: 18.0 requirements: - local_storage: node: my_storage relationship: type: AttachesTo properties: location: { get_input: storage_location } my_storage: type: tosca.nodes.Storage.BlockStorage properties: size: { get_input: storage_size } snapshot_id: { get_input: storage_snapshot_id }
my_server2: type: tosca.nodes.Compute capabilities: host: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 4096 MB os: properties: architecture: x86_64 type: Linux distribution: Fedora version: 18.0 requirements: - local_storage: node: my_storage2 relationship: type: AttachesTo properties: location: { get_input: storage_location } my_storage2: type: tosca.nodes.Storage.BlockStorage properties: size: { get_input: storage_size } snapshot_id: { get_input: storage_snapshot_id }
outputs: server_ip_1: description: The private IP address of the application’s first server. value: { get_attribute: [my_server, private_address] } server_ip_2: description: The private IP address of the application’s second server. value: { get_attribute: [my_server2, private_address] } volume_id_1: description: The volume id of the first block storage instance. value: { get_attribute: [my_storage, volume_id] } volume_id_2: description: The volume id of the second block storage instance. value: { get_attribute: [my_storage2, volume_id] } |
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > Tosca template for creating an object storage service.
topology_template: inputs: objectstore_name: type: string
node_templates: obj_store_server: type: tosca.nodes.Storage.ObjectStorage properties: name: { get_input: objectstore_name } size: 4096 MB maxsize: 20 GB |
Introduces the TOSCA Network and Port nodes used for modeling logical networks using the LinksTo and BindsTo Relationship Types. In this use case, the template is invoked without an existing network_name as an input property so a new network is created using the properties declared in the Network node.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with 1 server bound to a new network
topology_template:
inputs: network_name: type: string description: Network name
node_templates: my_server: type: tosca.nodes.Compute capabilities: host: properties: disk_size: 10 GB num_cpus: 1 mem_size: 4096 MB os: properties: architecture: x86_64 type: Linux distribution: CirrOS version: 0.3.2
my_network: type: tosca.nodes.network.Network properties: network_name: { get_input: network_name } ip_version: 4 cidr: '<IP_ADDRESS>/24' start_ip: '<IP_ADDRESS>' end_ip: '<IP_ADDRESS>' gateway_ip: '<IP_ADDRESS>'
my_port: type: tosca.nodes.network.Port requirements: - binding: my_server - link: my_network |
This use case shows how to use a network_name as an input parameter to the template to allow a server to be associated with an existing network.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with 1 server bound to an existing network
topology_template: inputs: network_name: type: string description: Network name
node_templates: my_server: type: tosca.nodes.Compute capabilities: host: properties: disk_size: 10 GB num_cpus: 1 mem_size: 4096 MB os: properties: architecture: x86_64 type: Linux distribution: CirrOS version: 0.3.2
my_network: type: tosca.nodes.network.Network properties: network_name: { get_input: network_name }
my_port: type: tosca.nodes.network.Port requirements: - binding: node: my_server - link: node: my_network |
This use case shows how two servers (Compute nodes) can be bound to the same Network (node) using two logical network Ports.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with 2 servers bound to the 1 network
topology_template:
inputs: network_name: type: string description: Network name network_cidr: type: string default: <IP_ADDRESS>/24 description: CIDR for the network network_start_ip: type: string default: <IP_ADDRESS> description: Start IP for the allocation pool network_end_ip: type: string default: <IP_ADDRESS> description: End IP for the allocation pool
node_templates: my_server: type: tosca.nodes.Compute capabilities: host: properties: disk_size: 10 GB num_cpus: 1 mem_size: 4096 MB os: properties: architecture: x86_64 type: Linux distribution: CirrOS version: 0.3.2
my_server2: type: tosca.nodes.Compute capabilities: host: properties: disk_size: 10 GB num_cpus: 1 mem_size: 4096 MB os: properties: architecture: x86_64 type: Linux distribution: CirrOS version: 0.3.2
my_network: type: tosca.nodes.network.Network properties: ip_version: 4 cidr: { get_input: network_cidr } network_name: { get_input: network_name } start_ip: { get_input: network_start_ip } end_ip: { get_input: network_end_ip }
my_port: type: tosca.nodes.network.Port requirements: - binding: my_server - link: my_network
my_port2: type: tosca.nodes.network.Port requirements: - binding: my_server2 - link: my_network |
This use case shows how three logical networks (Network), each with its own IP address range, can be bound to with the same server (Compute node).
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with 1 server bound to 3 networks
topology_template:
node_templates: my_server: type: tosca.nodes.Compute capabilities: host: properties: disk_size: 10 GB num_cpus: 1 mem_size: 4096 MB os: properties: architecture: x86_64 type: Linux distribution: CirrOS version: 0.3.2
my_network1: type: tosca.nodes.network.Network properties: cidr: '<IP_ADDRESS>/24' network_name: net1
my_network2: type: tosca.nodes.network.Network properties: cidr: '<IP_ADDRESS>/24' network_name: net2
my_network3: type: tosca.nodes.network.Network properties: cidr: '<IP_ADDRESS>/24' network_name: net3
my_port1: type: tosca.nodes.network.Port properties: order: 0 requirements: - binding: my_server - link: my_network1
my_port2: type: tosca.nodes.network.Port properties: order: 1 requirements: - binding: my_server - link: my_network2
my_port3: type: tosca.nodes.network.Port properties: order: 2 requirements: - binding: my_server - link: my_network3 |
TOSCA simple profile service showing the WordPress web application with a MySQL database hosted on a single server (instance).
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with WordPress, a web server, a MySQL DBMS hosting the application’s database content on the same server. Does not have input defaults or constraints.
topology_template: inputs: cpus: type: integer description: Number of CPUs for the server. db_name: type: string description: The name of the database. db_user: type: string description: The username of the DB user. db_pwd: type: string description: The WordPress database admin account password. db_root_pwd: type: string description: Root password for MySQL. db_port: type: PortDef description: Port for the MySQL database
node_templates: wordpress: type: tosca.nodes.WebApplication.WordPress properties: context_root: { get_input: context_root } requirements: - host: webserver - database_endpoint: mysql_database interfaces: Standard: create: wordpress_install.sh configure: implementation: wordpress_configure.sh inputs: wp_db_name: { get_property: [ mysql_database, name ] } wp_db_user: { get_property: [ mysql_database, user ] } wp_db_password: { get_property: [ mysql_database, password ] } # In my own template, find requirement/capability, find port property wp_db_port: { get_property: [ SELF, database_endpoint, port ] }
mysql_database: type: Database properties: name: { get_input: db_name } user: { get_input: db_user } password: { get_input: db_pwd } port: { get_input: db_port } capabilities: database_endpoint: properties: port: { get_input: db_port } requirements: - host: mysql_dbms interfaces: Standard: configure: mysql_database_configure.sh
mysql_dbms: type: DBMS properties: root_password: { get_input: db_root_pwd } port: { get_input: db_port } requirements: - host: server interfaces: Standard: inputs: db_root_password: { get_property: [ mysql_dbms, root_password ] } create: mysql_dbms_install.sh start: mysql_dbms_start.sh configure: mysql_dbms_configure.sh
webserver: type: WebServer requirements: - host: server interfaces: Standard: create: webserver_install.sh start: webserver_start.sh
server: type: Compute capabilities: host: properties: disk_size: 10 GB num_cpus: { get_input: cpus } mem_size: 4096 MB os: properties: architecture: x86_64 type: linux distribution: fedora version: 17.0
outputs: website_url: description: URL for Wordpress wiki. value: { get_attribute: [server, public_address] } |
Where the referenced implementation scripts in the example above would have the following contents
|
yum -y install wordpress |
|
sed -i "/Deny from All/d" /etc/httpd/conf.d/wordpress.conf sed -i "s/Require local/Require all granted/" /etc/httpd/conf.d/wordpress.conf sed -i s/database_name_here/name/ /etc/wordpress/wp-config.php sed -i s/username_here/user/ /etc/wordpress/wp-config.php sed -i s/password_here/password/ /etc/wordpress/wp-config.php systemctl restart httpd.service |
|
# Setup MySQL root password and create user cat << EOF | mysql -u root --password=db_root_password CREATE DATABASE name; GRANT ALL PRIVILEGES ON name.* TO "user"@"localhost" IDENTIFIED BY "password"; FLUSH PRIVILEGES; EXIT EOF |
|
yum -y install mysql mysql-server # Use systemd to start MySQL server at system boot time systemctl enable mysqld.service |
|
# Start the MySQL service (NOTE: may already be started at image boot time) systemctl start mysqld.service |
|
# Set the MySQL server root password mysqladmin -u root password db_root_password |
|
yum -y install httpd systemctl enable httpd.service |
|
# Start the httpd service (NOTE: may already be started at image boot time) systemctl start httpd.service |
This use case Instantiates a 2-tier application with Nodejs and its (PayPal sample) WebApplication on one tier which connects a MongoDB database (which stores its application data) using a ConnectsTo relationship.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > TOSCA simple profile with a nodejs web server hosting a PayPal sample application which connects to a mongodb database.
imports: - custom_types/paypalpizzastore_nodejs_app.yaml
dsl_definitions: ubuntu_node: &ubuntu_node disk_size: 10 GB num_cpus: { get_input: my_cpus } mem_size: 4096 MB os_capabilities: &os_capabilities architecture: x86_64 type: Linux distribution: Ubuntu version: 14.04
topology_template: inputs: my_cpus: type: integer description: Number of CPUs for the server. constraints: - valid_values: [ 1, 2, 4, 8 ] default: 1 github_url: type: string description: The URL to download nodejs. default: https://github.com/sample.git
node_templates:
paypal_pizzastore: type: tosca.nodes.WebApplication.PayPalPizzaStore properties: github_url: { get_input: github_url } requirements: - host:nodejs - database_connection: mongo_db interfaces: Standard: configure: implementation: scripts/nodejs/configure.sh inputs: github_url: { get_property: [ SELF, github_url ] } mongodb_ip: { get_attribute: [mongo_server, private_address] } start: scriptsscripts/nodejs/start.sh
nodejs: type: tosca.nodes.WebServer.Nodejs requirements: - host: app_server interfaces: Standard: create: scripts/nodejs/create.sh
mongo_db: type: tosca.nodes.Database requirements: - host: mongo_dbms interfaces: Standard: create: create_database.sh
mongo_dbms: type: tosca.nodes.DBMS requirements: - host: mongo_server properties: port: 27017 interfaces: tosca.interfaces.node.lifecycle.Standard: create: mongodb/create.sh configure: implementation: mongodb/config.sh inputs: mongodb_ip: { get_attribute: [mongo_server, private_address] } start: mongodb/start.sh
mongo_server: type: tosca.nodes.Compute capabilities: os: properties: *os_capabilities host: properties: *ubuntu_node
app_server: type: tosca.nodes.Compute capabilities: os: properties: *os_capabilities host: properties: *ubuntu_node
outputs: nodejs_url: description: URL for the nodejs server, http://<IP>:3000 value: { get_attribute: [app_server, private_address] } mongodb_url: description: URL for the mongodb server. value: { get_attribute: [ mongo_server, private_address ] } |
· Scripts referenced in this example are assumed to be placed by the TOSCA orchestrator in the relative directory declared in TOSCA.meta of the TOSCA CSAR file.
TOSCA simple profile service showing the Nodejs, MongoDB, Elasticsearch, Logstash, Kibana, rsyslog and collectd installed on a different server (instance).
This use case also demonstrates:
· Use of TOSCA macros or dsl_definitions
· Multiple SoftwareComponents hosted on same Compute node
· Multiple tiers communicating to each other over ConnectsTo using Configure interface.
TheThe following YAML is the primary template (i.e., the Entry-Definition) for the overall use case. The imported YAML for the various subcomponents are not shown here for brevity.
|
tosca_definitions_version: tosca_simple_yaml_1_3
description: > This TOSCA simple profile deploys nodejs, mongodb, elasticsearch, logstash and kibana each on a separate server with monitoring enabled for nodejs server where a sample nodejs application is running. The syslog and collectd are installed on a nodejs server.
imports: - paypalpizzastore_nodejs_app.yaml - elasticsearch.yaml - logstash.yaml - kibana.yaml - collectd.yaml - rsyslog.yaml
dsl_definitions: host_capabilities: &host_capabilities # container properties (flavor) disk_size: 10 GB num_cpus: { get_input: my_cpus } mem_size: 4096 MB os_capabilities: &os_capabilities architecture: x86_64 type: Linux distribution: Ubuntu version: 14.04
topology_template: inputs: my_cpus: type: integer description: Number of CPUs for the server. constraints: - valid_values: [ 1, 2, 4, 8 ] github_url: type: string description: The URL to download nodejs. default: https://github.com/sample.git
node_templates: paypal_pizzastore: type: tosca.nodes.WebApplication.PayPalPizzaStore properties: github_url: { get_input: github_url } requirements: - host: nodejs - database_connection: mongo_db interfaces: Standard: configure: implementation: scripts/nodejs/configure.sh inputs: github_url: { get_property: [ SELF, github_url ] } mongodb_ip: { get_attribute: [mongo_server, private_address] } start: scripts/nodejs/start.sh
nodejs: type: tosca.nodes.WebServer.Nodejs requirements: - host: app_server interfaces: Standard: create: scripts/nodejs/create.sh
mongo_db: type: tosca.nodes.Database requirements: - host: mongo_dbms interfaces: Standard: create: create_database.sh
mongo_dbms: type: tosca.nodes.DBMS requirements: - host: mongo_server interfaces: tosca.interfaces.node.lifecycle.Standard: create: scripts/mongodb/create.sh configure: implementation: scripts/mongodb/config.sh inputs: mongodb_ip: { get_attribute: [mongo_server, ip_address] } start: scripts/mongodb/start.sh
elasticsearch: type: tosca.nodes.SoftwareComponent.Elasticsearch requirements: - host: elasticsearch_server interfaces: tosca.interfaces.node.lifecycle.Standard: create: scripts/elasticsearch/create.sh start: scripts/elasticsearch/start.sh logstash: type: tosca.nodes.SoftwareComponent.Logstash requirements: - host: logstash_server - search_endpoint: elasticsearch interfaces: tosca.interfaces.relationship.Configure: pre_configure_source: implementation: python/logstash/configure_elasticsearch.py input: elasticsearch_ip: { get_attribute: [elasticsearch_server, ip_address] } interfaces: tosca.interfaces.node.lifecycle.Standard: create: scripts/lostash/create.sh configure: scripts/logstash/config.sh start: scripts/logstash/start.sh
kibana: type: tosca.nodes.SoftwareComponent.Kibana requirements: - host: kibana_server - search_endpoint: elasticsearch interfaces: tosca.interfaces.node.lifecycle.Standard: create: scripts/kibana/create.sh configure: implementation: scripts/kibana/config.sh input: elasticsearch_ip: { get_attribute: [elasticsearch_server, ip_address] } kibana_ip: { get_attribute: [kibana_server, ip_address] } start: scripts/kibana/start.sh