Explicit Substitutability

April 17, 2018

Introduction

The TOSCA substitution mappings feature allows orchestrators to substitute a single node template with an entire sub-topology that acts as an implementation for that node. This feature allows orchestrators to make deployment-time decisions about which technologies or which vendor products should provide functionality specified in service templates. It also allows orchestrators to adapt to changing scale or performance requirements at deployment-time (or even run-time).

Unfortunately, TOSCA doesn’t allow template designers to specify explicitly whether node templates are intended to be substituted or not. Instead, node templates areimplicitly determined to be substitutable when they are abstract.

This document proposes TOSCA grammar that allows service template designers to explicitly specify whether node templates are intended to be substituted.

Problems with Substituting Abstract Node Templates

TOSCA currently specifies that all abstract node templates must be substituted by the orchestrator.

TOSCA defines abstract node templates as follows (from the Glossary section):

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

Making substitution decisions based on whether a node template is abstract suffers from the following problems:

  1. Not all nodes without a create implementations are abstract
  2. Not all nodes use normative interfaces

Concrete Nodes without Create Implementation

There are a number of modeling scenarios where it is useful to include node templates without a create implementation in TOSCA service templates:

  1. Some node templates may represent physical devices that obviously don’t need to be orchestrated, and as a result must not have an implementation for the create operation of the Standard lifecycle operation. However, it may still be necessary to configure those devices, and as a result the node templates that represent those devices may need implementations for the configure operation of the Standard lifecycle interface. The current specification does not support this scenario:
  2. The orchestrator will attempt to substitute this node template, which will likely fail.
  3. If the orchestrator somehow managed to successfully substitute this node template, the configure operation will never get called.
  1. To make service templates more modular and more readable, it may sometimes be helpful to introduce node templates that have no other function than to “hold” properties that can be used by other node templates. An example of such an “informational” node template might be a “Subnet” node that holds information about an IP subnet mask and default gateway for a given network interface. Since this information might need to be used by multiple network interfaces, it might be helpful to separate this information into a separate “subnet” node and establish relationships to this subnet node from each of the interfaces that uses this info. In this scenario, the subnet node does not need to be orchestrated. However, using the current TOSCA specification, a TOSCA orchestrator will determine that the subnet node is abstract and as a result will attempt to substitute it.

To support these use cases, TOSCA should allow node templates that do not implement the create operation without substituting those node templates.

Non-Normative Interfaces

TOSCA orchestrators mark node templates as abstract if they do not have an implementation for the create operation of the normative tosca.interfaces.node.lifecycle.Standardinterface.

However, some node templates may not use the normative lifecycle management interfaces. They may use custom interfaces instead for managing their lifecycle. As long as those custom interfaces include an implementation that “creates” the node, that node should not be marked as abstract. However, based on the current specification, TOSCA will make an incorrect determination that such nodes are abstract and will try to substitute them.

This example shows that the algorithm used by TOSCA to determine whether nodes are abstract may not always return the correct result.

Explicit Substitutability

Based on the examples above, it is clear that the current mechanism for implicitly deciding whether node templates need to be substituted is error prone and may not always generate the desired result.

To address these shortcomings, we propose to allow service template designers to explicitly specify whether node templates need to be substituted or not. TOSCA orchestrators will only substitute those nodes that are explicitly marked for substitution by the service template designer.

We propose to use the directives keyname in node templates to specify that a node template must be specified, as shown in the following example template. The template allows a firewall service to be instantiated. The service template designer uses the directiveskeyname to specify that the abstract firewall node template needs to be substituted.

tosca_definitions_version: tosca_simple_yaml_1_2_0
description: Template for creating abstract firewallservice
topology_template:
node_templates:
firewall:
type: abstract.Firewall
directives:
-substitute

1