Tosca v1.2 and v1.3 enhancements 2019 05-06

TOSCA Enhancements—
Post v1.1
May 6, 2019

TOSCA Feature Categories
Copyright © 2019 Ubicity Corp. 2
Modeling Features
Topology, Node, and Relationship
Templates
Reusable Components (Types)
Requirements and Node Filters
Substitution
Orchestration Features
Interfaces, Operations, and
Notifications
Artifact Processing
Workflows
Policies

TOSCA v1.2 Enhancements

TOSCA Orchestration Examples
TOSCA is a language specification only
– Intentionally does not prescribe orchestrator
implementations
– To allow a rich ecosystem of TOSCA
implementation
However, user feedback suggests that
examples of orchestration
implementations might be useful:
– To avoid confusion about language features
– To simplify explanations of language features
– To improve portability
TOSCA Simple Profile in YAML v1.2
introduces non-normative chapters
describing orchestrator functionality
Chapter 13
– Artifact Processing and creating portable
Service Templates
Chapter 14
– Abstract nodes and target node filters matching

Orchestration Enhancements—Artifact Processing
Chapter 13 introduces the concept of
Artifact Processor
– Defines comprehensive set of artifact
processing steps
– Each artifact type is handled by its own artifact
processor
– To ensure portability, artifact processors must
define standard mechanism for exchanging
information with orchestrator
• Operation inputs and outputs
• Artifact properties
– TOSCA v1 currently only defines information
exchange standard for shell scripts
• Through environment variables
Notifications
Artifact Processing
Workflows
Policies

Orchestration Enhancements—Operation Implementations
Extended Operation Implementation
Grammar
1. Support for specifying execution environment
2. Support for timeout values
Notifications
Artifact Processing
Workflows
Policies

Extended Operation Implementation Grammar
interfaces:
Standard:
create:
implementation:
primary: artifacts/create.sh
operation_host : HOST
timeout : 100
Support for execution host
– Borrows from and generalizes workflow syntax
– Specifies the node on which operations should
be executed
– ORCHESTRATOR, SELF, or HOST for node
operations
– ORCHESTRATOR, SOURCE, or TARGET for
relationship operations
Support for timeout values
– Specifies how long orchestrator should wait for
operation to complete before it times out
– Expressed in seconds

Orchestration Enhancements—Policy Triggers
Policy trigger condition leverages the
condition clause definition introduced with
workflows in TOSCA v1.1
– Part of broader (and ongoing) effort to
harmonize workflow and policy syntax
Notifications
Artifact Processing
Workflows
Policies

Chapter 14—Matching
Non-normative chapter to ease
understanding of TOSCA orchestrator
matching process.
– Matching abstract node templates in service
templates with substituting service template (in
service catalog)
– Matching dangling requirements in node
templates with resources (in inventory) that have
the capability to fulfill the requirement
Unfortunately, Chapter 14 includes
incorrect examples
– V1.3 removes Chapter 14
– Corrected version of Chapter 14 will get re-
introduced in TOSCA v2.0
Modeling Features
Templates
Substitution

Modeling Enhancements—Substitution Mapping
– Substitution mappings allow complete mapping
of all Node Type keynames
Modeling Features
Templates
Substitution

Substitution Mapping
properties:
<property_name>: <property_value>
<property_name>: [<input_name>]
<property_name>: [<node_template_name>, <property_name>]
interfaces:
<interface_name>:
<operation_name>: <workflow_name>
Property Mappings
– Explicit property-to-input mappings
• Without requiring input names to
match
– Property-to-property mappings
• Deprecated in v1.3
– Property-to-constant-value
mappings
• Replaced with substitution_filter in
v1.3
Interface Mappings
– Operation-to-workflow mapping

Modeling Enhancements—Type Definitions
1. Additional String types
2. Schema constraints on strings
3. Abstract node types
Modeling Features
Templates
Substitution

String Data Type Enhancements
properties:
event_object:
type: tosca.datatypes.json
constraints:
- schema: >
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "Event",
"description": "Example Event type schema",
"type": "object",
"properties": {
"uuid": {
"description": "The unique ID for the event.",
"type": "string"
},
"code": {
"type": "integer"
},
"message": {
"type": "string"
}
},
"required": ["uuid", "code"]
}
tosca.datatype.json
– In support of ECMA-404 / IETF RFC 7158
• JSON Data Interchange Format
tosca.datatype.xml
– For XML-formatted strings
Schema constraint on string types.
– When supplied on a Property definition, a
TOSCA Orchestrator MAY choose use the
contained schema definition for validation
– Expects constraint schema to be supplied
in-line

Abstract Node Types
node_types:
tosca.nodes.Abstract.Compute:
derived_from: tosca.nodes.Root
tosca.nodes.Compute:
derived_from: tosca.nodes.Abstract.Compute
tosca.nodes.Abstract.Storage:
derived_from: tosca.nodes.Root
tosca.nodes.Storage.ObjectStorage:
derived_from: tosca.nodes.Abstract.Storage
tosca.nodes.Storage.BlockStorage:
derived_from: tosca.nodes.Abstract.Storage
capability_types:
tosca.capabilities.Container:
derived_from: tosca.capabilities.Root
tosca.capabilities.Compute:
derived_from: tosca.capabilities.Container
Create abstract base types for a number of
normative TOSCA node types
– Motivated by ETSI NFV requirements
– To extract properties that are common between
TOSCA node types and ETSI NFV information
models
Create abstract base types for a number of
normative TOSCA capability types
– In support of new abstract node types

TOSCA v1.3 Enhancements

Operation Output Mappings
tosca_definitions_version: tosca_simple_yaml_1_3
topology_template:
node_templates:
server:
type: tosca.nodes.Compute
interfaces:
Standard:
configure:
outputs:
ip1: [ SELF, private_address ]
ip2: [ SELF, public_address ]
Interface definitions formally define
output mappings that specify:
– The named output values that are
expected to be returned by interface
operations.
– The attributes on nodes or relationships
into which these output values must be
stored.
Enables instance model to accurately
reflect that state of the objects under
management.

Notifications in Interface Definitions
topology_template:
node_templates:
db_1:
type: org.ego.nodes.Database
interfaces:
HealthMonitor:
notifications:
heartbeat:
outputs:
tick: [ SELF, still_alive ]
failure_report:
outputs:
level: [SELF, failure_level]
time: [SELF, failure_time]
environment: [SELF, failure_context]
Interface notifications define events
that are delivered asynchronously to
the orchestrator
– As a result of external events (e.g. load
changes, failures, or other changes)
– Rather than as a result of lifecycle
management operations performed by the
orchestrator.
Interface notifications include output
mappings
– To allow the instance model to accurately
reflect the state of the objects under
management.

Orchestration Enhancements—Artifact Processing
1. Artifact properties
Notifications
Artifact Processing
Workflows
Policies

Artifact Properties
artifacts:
sw_image:
description: Image for virtual machine
type: tosca.artifacts.Deployment.Image.VM
file: images/vm_image.qcow2
checksum: ba411cafee2f0f702572369da0b765e2
version: 3.2
checksum_algorithm: MD5
properties:
name: vSRX
container_format: BARE
disk_format: QCOW2
min_disk: 1 GB
size: 649 MB
– Artifact Processors may need additional details
about artifacts (beyond the artifact type) to
process the artifact correctly
– This information is provided using artifact
properties
– TOSCA v1.2 includes property definitions in
artifact type definitions, but not property
assignments in artifact definitions
– TOSCA v1.3 fixes this oversight

Orchestration Enhancements—Workflows
1. Improved condition grammar
2. Harmonize actions/activities across workflows
and policies
3. External workflows
Notifications
Artifact Processing
Workflows
Policies

Improved Condition Clauses
condition:
- not:
- and:
- my_attribute1: [{equal: value1}]
- my_attribute2: [{equal: value1}]
condition:
- or:
- and:
- protocol: { equal: http }
- port: { equal: 80 }
- and:
- protocol: { equal: https }
- port: { equal: 431 }
– Condition clauses now support ‘not’ operator
– Condition clauses deprecate the (redundant)
assert statement

Harmonize Actions/Activities across Workflows and Policies
workflows:
deploy:
steps:
tomcat_install:
target: tomcat
activities:
- set_state: creating
- call_operation: org.example.if.std.create
- set_state: created
policies:
- recover_policy:
type: org.ego.policies.trigger.RecoveryPolicy
triggers:
- mon_fail_trigger:
action:
- delegate: failure_recovery_workflow
Workflow steps and policy triggers
both allow a set of activities to be
specified
– Unifies grammar that was inconsistent
in previous versions
Activities can include
– Set the state of a node
– Call an operation defined on a TOSCA
interface
– Inline another workflow
– Delegate to another workflow

External Workflows
topology_template:
workflows:
deploy:
implementation:
description: workflow implemented in Mistral
type: mycompany.artifacts.Mistral
file: my_workflow.workbook.mistral.yaml
outputs:
ip1: [ server, private_address ]
ip2: [ server, public_address ]
Allow service topologies to be
deployed and managed using non-
TOSCA workflows
– Specified using 3rd-party workflow
languages
– Packaged with service templates as
artifacts
Support output mappings for
external workflows
– To allow the instance model to accurately
reflect the state of the managed objects
after the external workflow has been run.

Orchestration Enhancements—Policies
1. Link policy trigger events to interface
notifications
Notifications
Artifact Processing
Workflows
Policies

Link Policy Trigger Events to Interface Notifications
policies:
- recover_policy:
type: org.ego.policies.trigger.RecoveryPolicy
description: >
Kicks in if the database or app_logic
nodes fail.
targets: [ db_1, app_logic_1 ]
triggers:
- mon_fail_trigger:
event: org.example.if.Monitor.on_failure
action:
- delegate: failure_recovery_workflow
...
– Policy triggers define event / condition /
action
– Events in policy triggers now refer to
newly-introduced notifications in
interface definitions
– Enables true closed-loop automation

Modeling Enhancements—Templates
1. Consistent use of ‘occurrences’ keyword in
capability definitions and capability
assignments.
2. Prepare for multiple node instances
Modeling Features
Templates
Substitution

Multiple Node Instances (Experimental)
topology_template:
inputs:
numberOfSites:
type: integer
node_templates:
sdwan:
type: VPN
site:
type: VPNSite
occurrences: [1, UNBOUNDED]
instance_count: { get_input: numberOfSites }
requirements:
- vpn: sdwan
Allow multiple node instances to be
created from the same node
template.
– For services with a variable number of
nodes of the same type.
• E.g. ONAP CCVPN use case
Grammar extensions
– ‘occurrences’ keyword to specify how
many instances are allowed
– ‘instance_count’ keyword to specify
desired number of instances at
deployment time

Modeling Enhancements—Types
1. Formalize grammar for refining entity definitions
2. Improved support for complex data types
Modeling Features
Templates
Substitution

Formalize Grammar for Refining Entity Definitions
capability_types:
tosca.capabilities.Endpoint:
derived_from: tosca.capabilities.Root
properties:
secure:
type: boolean
default: false
tosca.capabilities.Endpoint.Admin:
derived_from: tosca.capabilities.Endpoint
# Change Endpoint secure indicator to true
# from its default of false
properties:
secure: true
Derived types can refine properties
defined in base types.
– A property definition is a refinement when a
property with the same name already exists
in a base type.
Property refinements can:
– Assign a new (compatible) property type
– Assign a (final) fixed value
– Specify or change a default value
– Add constraints.
– Turn an optional property into a required
property.
Refinement grammar for capability,
requirement, and interface definitions
to be formalized in future versions.

Improved Support for Complex Data Types
data_types:
DailyTasks:
derived_from: map
entry_schema:
type: list
entry_schema:
type: Task
key_schema:
type: DayOfWeek
Nested complex types
– List of lists
– List of maps
– Map of lists
– Map of maps
Datatypes that derive from list or map
– Add entry_schema
Support for key_schema
– To define the type of keys in maps
get_input support for complex data types
– Extract sub-elements of complex data types

Modeling Enhancements—Requirements
None
Modeling Features
Templates
Substitution

Modeling Enhancements—Substitution
1. Explicit substitutability
2. Property mapping corrections
3. Substitution filter
4. Multiple top-level templates in CSAR
Modeling Features
Templates
Substitution

Explicit Substitutability
topology_template:
inputs:
vendorInput:
type: string
rulesInput:
type: list
entry_schema: FirewallRules
node_templates:
firewall:
type: abstract.Firewall
directives:
- substitute
properties:
vendor: { get_input: vendorInput }
rules: { get_input: rulesInput }
Version 1.2 orchestrators are expected
to substitute abstract node templates
– Node templates were considered abstract if
no implementation was provided for create
operation of Standard lifecycle management
interface.
Issues with v1.2 approach:
– Does not work with custom interfaces.
– Behavior is orchestrator-specific.
– Does not allow for ‘dummy’ data structure
nodes.
V1.3 introduces explicit substitute
directive
– Service designer controls substitutability

Substitution mappings support the following
– Property-to-input mappings
• Mapping of properties of an abstract node to inputs of its substituting template.
– Property-to-property mappings have been deprecated
• Mapping of properties of an abstract node to properties of nodes in its substituting template.
• If substituting template is valid, all its nodes already have property values assigned, which makes property-to-
property mapping unnecessary/impossible.
– Property-to-constant mappings have been deprecated
• The mapping of a (variable) property to a constant value is confusing and counter-intuitive
• This feature was not intended to imply a mapping at all, but rather was intended to be used as a mechanism for
controlling the selection of a substituting template when multiple substitution candidates are available.
• Selection control has been formalized instead using substitution_filter grammar.
Property Mapping Corrections

Substitution Filters
description: Service template for an ACME firewall
topology_template:
inputs:
rulesInput:
type: list
entry_schema: FirewallRules
substitution_mappings:
node_type: abstract.Firewall
substitution_filter:
properties:
vendor: { equal: ACME }
properties:
rules: [ rulesInput ]
node_templates:
acme:
type: ACMEFirewall
properties:
rules: { get_input: rulesInput }
acmeConfig: # ACME-specific properties go here.
Used by substituting template to limit
the set of abstract node templates for
which it is a substitution candidate
Template is candidate for substitution if:
– The type in the substitution_mappings
section matches the type of the abstract
node template.
– The property values of the abstract node
template satisfy the constraints defined in the
substitution_filter

Multiple Top-Level Templates in CSAR
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
– Substitution mapping requires
Orchestrator to have access to one or
more substituting service templates
– These templates cannot be included into
top-level service template using import
statements
• Would result in multiple
topology_template statements in the
same service template
– Instead:
• Package substituting templates as top-level
templates in CSAR
• Use Other-Definitions statement in
TOSCA.meta to point to those other top-
level templates

Tosca v1.2 and v1.3 enhancements 2019 05-06

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Tosca v1.2 and v1.3 enhancements 2019 05-06

Similar to Tosca v1.2 and v1.3 enhancements 2019 05-06 (20)

Recently uploaded

Recently uploaded (20)

Tosca v1.2 and v1.3 enhancements 2019 05-06