THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Currently ONAP uses a TOSCA 1.1 Simple YAML profile to create service models. However, these models cannot be validated by AriaTosca until it supports 1.1 (AriaTosca currently supports 1.0 only).
Service-template Type
The extension of the service-template can be 'yaml' or 'yml'. Currently, aria supports only 'yaml' extension.
Changes/Updates from Simple Profile 1.0
Namespace URI and Namespace Alias
As it is the new profile defintion, it comes with changed profile definitino namespace URI and alias.
- Namespace URI: http://docs.oasis-open.org/tosca/ns/simple/yaml/1.1
- Namespace Alias: tosca_simple_yaml_1_1
3.6 Type specific definitions
3.6.4 Artifact Type, 3.6.5 Interface Type, 3.6.6 Data Type, 3.6.7 Capability Type, 3.6.9 Node Type, 3.6.10 Relationship Type, 3.6.11 Group Type, 3.6.12 Policy Type
Updated to support the common keynames listed in newly added abstract type TOSCA Entity Schema. This TOSCA Entity Schema includes four properties named derived_from, version, metadata, description. metadata in the new property which will get added to all these types.
| Key | Type | Mandatory | Description |
|---|---|---|---|
| metadata | map of Strings | No | Defines a section used to declare additional metadata information. |
Example:
<Type_name>:
type: <TOSCA type>
metadata:
creation_date: 2015-04-14
date_updated: 2015-05-01
status: developmental
3.6.10 Group Type
Following three new attributes added.
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| attributes | List of attributed definitions | No | An optional list of attribute definitions for the Group Type |
| requirements | List of requirements definitions | No | An optional sequenced list of requirement definitions for the Group Type. |
| capabilities | List of capabilities definitions | No | An optional list of capability definitions for the Group Type. |
Example:
3.6.12 Policy Type
Following new attribute added.
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| triggers | List of trigger | No | An optional list of policy triggers for the Policy types |
Example:
Definition of a Trigger
| Keyname | Mandatory | Type | Description |
|---|---|---|---|
description | no | description | The optional description string for the named trigger. |
event_type | yes | string | The required name of the event type that activates the trigger’s action. |
schedule | no | TimeInterval | The optional time interval during which the trigger is valid (i.e., during which the declared actions will be processed). |
target_filter | no | event filter | The optional filter used to locate the attribute to monitor for the trigger’s defined condition. This filter helps locate the TOSCA entity (i.e., node or relationship) or further a specific capability of that entity that contains the attribute to monitor. |
condition | no | constraint clause | The optional condition which contains an attribute constraint that can be monitored. Note: this is optional since sometimes the event occurrence itself is enough to trigger the action. |
constraint | no | constraint clause | The optional condition which contains an attribute constraint that can be monitored. Note: this is optional since sometimes the event occurrence itself is enough to trigger the action. |
period | no | scalar-unit.time | The optional period to use to evaluate for the condition. |
evaluations | no | integer | The optional number of evaluations that must be performed over the period to assert the condition exists. |
method | no | string | The optional statistical method name to use to perform the evaluation of the condition. |
action | yes | string or operation | The if of the workflow to be invoked when the event is triggered and the condition is met (i.e, evaluates to true). Or The required operation to invoke when the event is triggered and the condition is met (i.e., evaluates to true). |
3.7 Template-specific definitions
Abstract Node Template
An abstract node template is a node that doesn’t define an implementation artifact for the create operation of the TOSCA lifecycle. The create operation can be delegated to the TOSCA Orchestrator. Being delegated an abstract node may not be able to execute user provided implementation artifacts for operations post create (for example configure, start etc.).
No-Op Node Template
A No-Op node template is a specific abstract node template that does not specify any implementation for any operation.
3.7.3 Node Template, 3.7.4 Relationship Template, 3.7.5 Group definition, 3.7.6 Policy definition
Following new attribute added.
- metadata - Defines a section used to declare additional metadata information.
5.5 Capabilities Types
5.5.6 tosca.capabilities.Container
It is now derived from derived from new capability type tosca.capabilities.Compute
5.9.8 tosca.nodes.ObjectStorage
Changed to tosca.nodes.Storage.ObjectStorage
5.9.9 tosca.nodes.BlockStorage
Changed to tosca.nodes.Storage.BlockStorage
Substitution Mapping
TBU
Additions to Simple Profile 1.0
3.5 Reusable modeling definitions
3.5.15 Event Filter definition
An event filter definition defines criteria for selection of an attribute, for the purpose of monitoring it, within a TOSCA entity, or on its capabilities.
3.5.16 Trigger definition
A trigger definition defines the event, condition and action that is used to “trigger” a policy it is associated with.
3.5.17 Workflow activity definition
A workflow activity defines an operation to be performed in a TOSCA workflow. Activities allows to:
- Delegate the workflow for a node expected to be provided by the orchestrator
- Set the state of a node
- Call an operation defined on a TOSCA interface of a node, relationship or group
- Inline another workflow defined in the topology (to allow reusability)
3.5.18 Assertion definition
A workflow assertion is used to specify a single condition on a workflow filter definition. The assertion allows to assert the value of an attribute based on TOSCA constraints.
3.5.19 Condition clause definition
A workflow condition clause definition is used to specify a condition that can be used within a workflow precondition or workflow filter.
3.5.20 Workflow precondition definition
A workflow condition can be used as a filter or precondition to check if a workflow can be processed or not based on the state of the instances of a TOSCA topology deployment. When not met, the workflow will not be triggered.
3.5.21 Workflow step definition
A workflow step allows to define one or multiple sequenced activities in a workflow and how they are connected to other steps in the workflow. They are the building blocks of a declarative workflow.
3.6 Type specific definitions
3.6.1 Entity Type Schema
An Entity Type is the common, base, polymorphic schema type which is extended by TOSCA base entity type schemas (e.g., Node Type, Relationship Type, Artifact Type, etc.) and serves to define once all the commonly shared keynames and their types. This is a “meta” type which is abstract and not directly instantiatable.
3.7 Template-specific definitions
3.7.7 Imperative workflow definition
A workflow definition defines an imperative workflow that is associated with a TOSCA topology.
3.8 Topology Template definition
Topology template includes workflows.
5.3 Data Types
5.3.3 tosca.datatypes.TimeInterval
The TimeInterval type is a complex TOSCA data Type used when describing a period of time using the YAML ISO 8601 format to declare the start and end times.
5.5 Capabilities Types
5.5.3 tosca.capabilities.Compute
The Compute capability, when included on a Node Type or Template definition, indicates that the node can provide hosting on a named compute resource.
5.5.4 tosca.capabilities.Network
The Storage capability, when included on a Node Type or Template definition, indicates that the node can provide addressiblity for the resource a named network with the specified ports.
5.5.5 tosca.capabilities.Storage
The Storage capability, when included on a Node Type or Template definition, indicates that the node can provide a named storage location with specified size range.
7 TOSCA workflows
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.