TOSCA Enhancements for Input-DrivenSubstitution Mapping
Chris Lauwers
March 25, 2018
Introduction
TOSCA allows abstract node templates to be substituted with concrete service templates at deployment time. This feature can be used to select from a number of alternative implementations of generic functionality at deployment time. When multiple alternative service templates are available that all implement the same generic functionality, users need a mechanism to select which implementation should be used for their deployment.
TOSCA Simple Profile v1.2 overloads the substitution_mappings grammar to allow service template designers to control matching as follows:
-The substitution mappings grammar is intended to map properties/capabilities/requirements from a substituted node onto inputs/properties/capabilities/requirements in a substituting node template.
-However, the substitution mappings grammar also allows for mapping onto a static value. If a static value is specified, then that value is used for matching (as opposed to for mapping) and only those node templates for which the property value matches the static value can be substituted by the service template.
The problem with this approach is that it mixes mapping and matching in the same substitution mappings grammar, which results in confusing and non-intuitive service templates. A better approach is to cleanly separate the mapping and matching functionality as follows:
-Use substitution_mappings to support mapping exclusively by removing support for mapping onto static values.
-Provide explicit support for controlling matching. TOSCA already includes support for controlling matching using the node_filter grammar.
This document shows how node filters can be used in conjunction with substitution_mappingsto drive the service template selection process.
Abstract Firewall Node Type
Let’s assume we’re trying to create an abstract security service that includes a firewall component. To represent this firewall component, we’re creating an abstract firewall node type as shown in the following code snippet:
tosca_definitions_version: tosca_simple_yaml_1_2description: Template defining an abstract firewall component
node_types:
abstract.Firewall:
derived_from: tosca.nodes.Root
properties:
vendor:
type: string
rules:
type: list
entry_schema: FirewallRules
The abstract firewall node type defines a rules property to hold the firewall rules. In addition, it also defines a property for capturing the name of the vendor of the firewall.
Vendor-Specific Firewall Templates
Let’s assume we have two firewall vendors who each provide implementations for the abstract firewall component using the vendor-specific service templates as shown below.
ACME Firewall’s service template looks as follows:
tosca_definitions_version: tosca_simple_yaml_1_2description: Service template for an ACME firewall
topology_template:
inputs:
rulesInput:
type: list
entry_schema: FirewallRules
substitution_mappings:
node_type: abstract.Firewall
properties:
rules: [ rulesInput ]
node_templates:
acme:
type: ACMEFirewall
properties:
rules: { get_input: rulesInput }
acmeConfig: # any ACME-specific properties go here.
Similarly, Simple Firewall’s service template looks as follows:
tosca_definitions_version: tosca_simple_yaml_1_2description: Service template for a Simple Corp. firewall
topology_template:
inputs:
rulesInput:
type: list
entry_schema: FirewallRules
substitution_mappings:
node_type: abstract.Firewall
properties:
rules: [ rulesInput ]
node_templates:
acme:
type: SimpleFirewall
properties:
rules: { get_input: rulesInput }
As the substitution mappings section in the service templates show, either firewall can be used to implement the abstract firewall component defined above.
Specifying Firewall Vendor
The following service template shows a service template that includes an abstract firewall component. In addition, it includes an input variable that allows users to specify a firewall from a specific vendor at deployment time.
tosca_definitions_version: tosca_simple_yaml_1_2description: Service template for an abstract security service
topology_template:
inputs:
vendorInput:
type: string
rulesInput:
type: list
entry_schema: FirewallRules
node_templates:
firewall:
type: abstract.Firewall
properties:
vendor: { get_input: vendorInput }
rules: { get_input: rulesInput }
Using Node Filters
The following template show a TOSCA extension that uses node filters to map the appropriate vendor-specific service templates onto the abstract firewall node template based on the value of the vendor property:
tosca_definitions_version: tosca_simple_yaml_1_2description: Service template for an ACME firewall
topology_template:
inputs:
rulesInput:
type: list
entry_schema: FirewallRules
substitution_mappings:
node_type: abstract.Firewall
node_filter:
properties:
-vendor: { equal: ACME }
properties:
rules: [ rulesInput ]
node_templates:
acme:
type: ACMEFirewall
properties:
rules: { get_input: rulesInput }
acmeConfig: # any ACME-specific properties go here.
The substitution mappings grammar is extended with a node_filterkeyname that is intended to narrow down which node templates can be substituted by this service template. In the example above, only abstract firewall node templates that have the vendor property set to ACME can be substituted by this service template.
The updated service template for Simple Corp’s firewall looks as follows:
tosca_definitions_version: tosca_simple_yaml_1_2description: Service template for a Simple Corp. firewall
topology_template:
inputs:
rulesInput:
type: list
entry_schema: FirewallRules
substitution_mappings:
node_type: abstract.Firewall
node_filter:
properties:
-vendor: { equal: Simple }
properties:
rules: [ rulesInput ]
node_templates:
acme:
type: SimpleFirewall
properties:
rules: { get_input: rulesInput }
As specified in this example, only abstract firewall node templates that have the vendor property set to Simple can be substituted by this service template.
Conclusion
TOSCA’s substitution mappings grammar should be extended with node filter support to allow users to specify specific service templates using input variables.
1