1. TOSCA Matching
Or how the orchestrator provides implementation for abstract nodes or dangling requirements.

2. TOSCA Type Catalog TOSCA allow users to define Node Types that can be
Abstract
They don’t provide implementation
They can be used in a topology template to request the orchestrator to find a matching implementation
Concrete
They define an implementation that may
Be based on artifacts (shell scripts, python scripts etc.)
May be actually a full Topology Template that is a Topology template
Both abstract and concrete types may define some properties that may be used for
Configuration purpose
Matching purpose

3. Matching an “Abstract Node Template”
A node type is compatible for matching as concrete implementation for an abstract node template if:
The type of the node is:
the same as the one specified by the node template
OR derive from the one specified by the node template
Every property value defined
On the node template
AND On the capabilities of the node template
Matches the constraints specified on the node type

4. Matching an “Abstract Node Template”
node_types:
tosca.samples.nodes.MyAbstractNode:
derived_from: tosca.nodes.Root
properties:
str_prop:
type: string
nbr_prop:
type: integer
topology_template:
node_templates:
my_node:
type: tosca.samples.MyAbstractNode
properties:
str_prop: standard
nbr_prop: 10
node_types:
tosca.samples.nodes.MyNodeImpl1:
derived_from: tosca.samples.nodes.MyAbstractNode
properties:
nbr_prop :
constraints:
- greater_or_equal: 1
interfaces:
standard:
create: test.sh
node_types:
tosca.samples.nodes.MyNodeImpl2:
derived_from: tosca.samples.nodes.MyAbstractNode
properties:
nbr_prop :
constraints:
- greater_or_equal: 25
interfaces:
standard:
create: test.sh

5. Concrete example: tosca.nodes.Compute
topology_template:
node_templates:
my_node:
type: tosca.nodes.Compute
node_types:
tosca.samples.nodes.MyCloudCompute:
derived_from: tosca.nodes.Compute
properties:
image_id:
type: string
required: true
flavor_id:
This defines an implementation to instantiate a compute node on my cloud (could be aws, azure, google cloud, openstack, custom etc.)
Note: we could specify in_range constraints to limit the host capabilities to the supported flavors or specify some valid values for os capabilities based on available images.
We just want a compute (basically a machine with infra power (host) and operating system on which I will be able to host (install) softwares. This could be substituted with many different implementation that provide such service.
The specific cloud implementation however requires image_id and flavor_id, after matching, the orchestrator should request them as an additional deployment parameter.
PROS: does not restrict the user
CONS: Some users may not want to bother managing image_id and flavor_id.
Question: how can I define pre-defined values to ease users life?

6. How to add pre-defined templates in a type catalog ?
Orchestrator specific/internal pre-defined template catalog
Orchestrators usually have a provider catalog
The orchestrator has a specific option to do that. This may be a valid solution for multiple use-case as orchestrator may also allow to configure specific supported data (authorizations, segregation to target clouds (not all elements can be associated together even if matching a parent contract: aws network for aws compute) etc).
Add some pre-defined sub-types
Leverage a node type with constraints
If your orchestrator does not support post-matching properties this is a valid choice
node_types:
tosca.samples.nodes.mycloudcompute.SmallUbuntu:
derived_from: tosca.samples.nodes.MyCloudCompute
properties:
image_id: { constraints: [ { equal: ubuntu_trusty } ] }
flavor_id: { constraints: [ { equal: small} ] }
capabilities:
host:
num_cpus: 1
cpu_frequency: 1 GHz
disk_size: 15 GB
mem_size: 2 MB
Note: Even this pre-defined templates could be partial. Meaning that some properties may be left for user to configure after matching (or if a specific concrete implementation node is chosen in a topology)
For example on an AWS compute node the security_groups property could be left open for user and not specified in a template.
Extra properties that may be implementation specific should be provided through orchestrator specific ways (Post matching UI screen, API options, Additional file etc.)

7. Matching a “Dangling Requirement”
Dangling Requirement defines a Capability Type (required) and eventually a specific Node Type and/or Node Filter
A node type is compatible for matching a Dangling requirement as concrete implementation if:
The node type has a capability with the same type as specified by the dangling requirement
If the node property is specified the Node Type is equal or derive from the specified Node Type
The node filter constraints are compatible/matched by the candidate node type

8. Matching a “Dangling Requirement”
Node Filter matching:
The properties of the candidate Node Type must be compatible with the properties definition filters specified in the node filter.
If some capability types or name are specified then the candidate Node Type must define capabilities with the requested names or types.
In addition if some properties filters are defined for the given capability then the candidate node type capability evaluated must have properties definition that are compatible with the requested filters.

9. Matching a “Dangling Requirement”
capability_types:
tosca.samples.capabilities.MyMessagingEndpoint :
derived_from: tosca.capabilities.Endpoint
properties:
throughput :
type: integer
required: true
node_types:
tosca.samples.nodes.MyNode :
derived_from: tosca.nodes.Root
requirements: tosca.samples.capabilities.MyMessagingEndpoint
interfaces:
standard:
create: install.sh
tosca.samples.nodes.MyAbstractMessagingSystem:
scaling:
type: string
constraints:
- valid_values: [ “auto”, ”manual”, “none” ]
highly_available :
type: boolean
capabilities:
messaging: tosca.samples.capabilities.MyMessagingEndpoint
Abstract nodes, capabilities and template to match:
topology_template:
node_templates:
my_node:
type: tosca.samples.nodes.MyNode
requirements:
- messaging:
node: tosca.samples.nodes.MyAbstractMessagingSystem
node_filter:
properties:
- scaling: { equal: auto }
- highly_available: { equal: true }
capabilities:
- tosca.samples.capabilities.MyMessagingEndpoint:
- throughput: { greater_than: 10 }

10. Matching a “Dangling Requirement”
capability_types:
tosca.samples.capabilities.MyLimitedMessagingEndpoint :
derived_from: tosca.samples.capabilities.MyMessagingEndpoint
properties:
throughput :
type: integer
required: true
constraints:
- lower_than: 5
node_types:
tosca.samples.nodes.MyMessagingSystem:
derived_from: tosca.samples.nodes.MyAbstractMessagingSystem
scaling :
type: string
- valid_values: [ “none”]
highly_available:
- equal: false
capabilities:
messaging: tosca.samples.capabilities.MyLimitedMessagingEndpoint
interfaces:
standard:
create: install.sh
start: start.sh
Some concrete nodes:
node_types:
tosca.samples.nodes.MyMessagingServiceSystem:
derived_from: tosca.samples.nodes.MyAbstractMessagingSystem
properties:
scaling :
type: string
required: true
constraints:
- valid_values: [ “manual”]
highly_available:
- equal: true
interfaces:
standard:
create: create.py

11. = A concrete node type from a topology template (substitution)
inputs:
# Nodes in this topology can be configured to enable auto-scaling or not
scaling_input :
type: string
required: true
constraints:
- valid_values: [ “auto”, “none” ]
# This topology is H.A.
highly_available_input : true # this is a constant input that will translate as a property definition with equal constraints.
substitution_mappings:
node_type: tosca.samples.nodes.MyAbstractMessagingSystem
properties:
scaling: scaling_input
highly_available: highly_available_input
capabilities:
messaging : [ my_load_balancer, load_balanced_messaging_endpoint]
node_templates:
my_load_balancer:
type: tosca.samples.nodes.MyLoadBalancer
capability:
load_balanced_messaging_endpoint: tosca.samples.capabilities.MyMessagingEndpoint
my_other_node_that_trigger_a_service_somewhere:
type: org.custom.Type
my_scaling_info: get_input { scaling }
my_other_node:
type: org.something.Type:
my_other_scaled_prop: get_input { scaling }
another_prop: value
… other nodes templates
A concrete node type from a topology template (substitution)
Note: The topology template with substitution is, from consumer point of view identical to the tosca.samples.nodes.MyMessagingSystem node type, exept the valid values for the scaling and the value of the highly_available property.
node_type:
my_node_resulting_from_topology
# From topology_template -> substitution_mappings -> node_type
derived_from: tosca.samples.nodes.MyAbstractMessagingSystem
properties:
scaling :
constraints:
- valid_values: [ “auto”, “none” ]
highly_available:
default: true
- equal: true
# Equivalent:
# implementation: The topology specified on the right =

12. Constraints compatibility matching examples
When both the node filter and the node type specifies constraints the orchestrator should consider the node type as a valid match if the constraints are compatible and a merged constraint can be created from them
Note that similar behavior exists when a topology input is used in mutliple node template properties. The same input constraint should be compatible across each property.
The value that the user will have to provide after matching or that the orchestrator will automatically use must be compliant with the resultant merged constraint.

13. Constraints compatibility matching examples
Node filter property constraint:
equal: 2
Candidate node type/capability property constraint:
No constraints => Match
equal: 2 => Match
equal: 3 => No match
valid_values: [1, 2, 10] => Match
valid_values: [1, 5, 10] => No match
greater_than: 1 => Match
greater_than: 5 => no match
lower_than: 5 => Match
in_range: [2, 10 ] => Match

14. Constraints compatibility matching examples
Node filter property constraint:
greater_or_equal: 2
Candidate node type/capability property constraint:
No constraints => Match
equal: 2 => Match
equal: 3 => Match
valid_values: [1, 2, 10] => Match
valid_values: [1, 5, 10] => Match
greater_than: 1 => Match
greater_than: 5 => Match
lower_than: 5 => Match
in_range: [2, 10 ] => Match
lower_than: 2 => No match

15. Post matching missing properties
The orchestrator must build a template in order to deploy an element. In order to do so it may require some additional property values.
When matching from types and some properties are missing after the matching the orchestrator should
Either request properties from the user
Either try to find a valid-value (based on default values and expressed constraints)
If an orchestrator cannot prompt user and no constraint or default allow to find a value for a required property the the node type should not be considered as a match.

16. Optional/specific catalogs: Pre-defined templates to match
Most TOSCA implementation will probably in addition to a Node Type catalog manage a catalog of fully or partially pre-defined Node Templates.
Fully predefined Node template means that there is no more property to be configured and the node is ready to deploy
Partially means that after matching in a topology the orchestrator may allow the definition of some of the properties for specific configuration/tuning
Theses node may not be part of a topology but may be used for quick matching.
Most of implementations have such internal catalog (for example to associate cloud ImageIds and Flavors to Compute nodes).
Management of such catalog is orchestrator specific and not defined in the specification.
A UI could help to create such templates from types.
Orchestrators could even allow to refine matching rules (for example default the matching of compute cpu to greater or equal values rather than equal)

17. Optional/specific catalogs: Running instances
The orchestrator may also allow definition of running instances to match on.
Running instances will be matched and may have specific lifecycle that won’t be managed by the TOSCA orchestrator.
TOSCA orchestrator may disable injection of some relationship operations or sandbox their execution for role/security isolation constraints.
Theses constraints and management are not yet specified in TOSCA and while this could be subject of future discussion such rules may remain orchestrator specific as it goes beyond the prime goal of TOSCA.

18. Portable Topology Template TOSCA Matching Engine TOSCA Catalog(s)
TOSCA Orchestrator
USER
Portable Topology Template
TOSCA Matching Engine
TOSCA Catalog(s)
Abstract Node Templates
(e.g. tosca.nodes.Compute, tosca.nodes.Database etc.)
Compatible node is a node that:
Is or derive from the specified type
Defines compatible properties
Matching engine is responsible for finding a concrete implementation for any Abstract Node Template or any Dangling requirement within the orchestrator catalog.
Note that matching engine may have some vendor specific features like UI to select a specific node when multiple are valid matches/candidates.
Type Catalog
(cannot be matched but exist in catalog)
Concrete (implemented) types
(Optional candidates for matching)
(Optional) Provider catalog
Orchestrator specific internal template/types
Dangling requirements with node filters.
(tosca.capabilities.MyAPIEndpoint)
Compatible node is a node that:
Defines a compatible capability (type is or derive from the specified capability type)
Matches the optional node filter constraints
(Optional) Pre-defined Node templates
Concrete types with pre-configured values. Note that there is no such definition in TOSCA so this is orchestrator specific definitions.
(Optional) Running instances
Already running instances