You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

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).

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.

 

 

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.

 

3.6.10 Relationship Type

 

Following three new attributes added.

 

  • attributes - An optional list of attribute definitions for the Group Type.
  • requirements - An optional sequenced list of requirement definitions for the Group Type.
  • capabilities - An optional list of capability definitions for the Group Type.

 

3.6.12 Policy Type

 

Following new attribute added.

 

  • triggers - An optional list of policy triggers for the Policy Type.

 

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.

 



 

  • No labels