Node template

Edit (pull request)

A Node Template specifies the occurrence of a manageable software component as part of an application’s topology model which is defined in a TOSCA Service Template. A Node template is an instance of a specified Node Type and can provide customized properties, constraints or operations which override the defaults provided by its Node Type and its implementations.

If a node template name contains some special character (is: not an alphanumeric character from the basic Latin alphabet and the underscore) we will replace this caractere by an underscore.

Keynames

The following is the list of recognized keynames recognized for a TOSCA Node Template definition and parsed by Alien4Cloud:

Keyname Required Description
type yes The required name of the Node Type the Node Template is based upon.
requirements no An optional sequenced list of requirement definitions for the Node Template.
properties no An optional list of property values for the node template.
capabilities no An optional map of capabilities for the node template.
interfaces no An optional list of named interface definitions that override those coming from type.

Grammar

The overall structure of a TOSCA Node Template and its top-level key collations using the TOSCA Simple Profile is shown below:

<node_template_name>:
  type: <node_type_name>
  properties:
    <property_definitions>
  requirements:
    <requirement_definitions>
  capabilities:
    <capability_definitions>
  interfaces:
    <interface_definitions>

type

Represents the name of the Node Type the Node Template is based upon. This Node Type must be found in the archive itself or in the declared dependencies of the service template.

requirements

To define relationships between node templates, you can describe the requirements that points to targets’ capability. Named requirement definitions have one of the following grammars:

short notation (node only)

<requirement_name>: <template_name>

When using this short notation:

  • the must match to the name of the requirement in the type definition.
  • the points to another node template in the topology template (relationship target).
  • the type of the node template target must have a capability named like the requirement.

Here is an example :

topology_template:
  node_templates:
    compute:
      type: tosca.nodes.Compute
    apache:
      type: alien.nodes.Apache
      requirements:
        # the alien.nodes.Apache type defines a requirement named 'host'
        # the tosca.nodes.Compute type defines a capability named 'host'
        - host: compute

short notation (with relationship or capability)

In some situations, the short notation is not enough, for example when the capability name doesn’t match the requirement name (in this case, you must specify the capability type), or when you want to define relationship properties values.

The following grammar would be used if either a relationship or capability is needed to describe the requirement:

<requirement_name>:
  node: <template_name>
  capability: <capability_type>
  relationship: <relationship_type>

In such notation the keywords are:

Keyname Required Description
node yes The relationship target node template name.
capability yes The type of the target node type capability that should be used to build the relationship.
relationship no Optionally, the name of the relationship type that should be used to build the relationship (if not defined in the requirement definition or must be specified).
properties no An optional list of property values for the relationship (non TOSCA).
interfaces no An optional list of named interface definitions that override those coming from relationship type.

In the following example, the relationship type is found in the requirement ‘database’ of the type alien.nodes.Wordpress. The capability is found by the specified type ‘alien.capabilities.MysqlDatabase’ :

node_templates:
  wordpress:
    type: alien.nodes.Wordpress
    requirements:
      - host: apache
      - database:
          node: mysql
          capability: alien.capabilities.MysqlDatabase
      - php:
          node: php
          capability: alien.capabilities.PHPModule

In the following example, the relationship is specified:

node_templates:
  compute:
    type: tosca.nodes.Compute
    requirements:
      - network:
          node: network
          capability: tosca.capabilities.Connectivity
          relationship: tosca.relationships.Network
  network:
    type: tosca.nodes.Network

properties

The property values can either be:

  • a scalar value
  • a function: a reference to an input

In the following example, 2 properties are defined for the node ‘compute1’ (1 referencing an input, and the other defined using a scalar value):

topology_template:
  inputs:
    os_type:
      type: string
      constraints:
        - valid_values: ["linux", "aix", "mac os", "windows"]
      description: The host Operating System (OS) type.
  node_templates:
    compute1:
      type: tosca.nodes.Compute
      properties:
        os_type: { get_input: os_type }
        mem_size: 1024

capabilities

In the following example, we define the value of the property ‘port’ for the capability named ‘database_endpoint’ of the node ‘mysql_database’:

topology_template:
  node_templates:
    mysql_database:
      type: tosca.nodes.Database
      capabilities:
        database_endpoint:
          properties:
            port: 3306

Note that the property value can also be a get_input function:

topology_template:
  inputs:
    mysql_port:
      type: string
  node_templates:
    mysql_database:
      type: tosca.nodes.Database
      capabilities:
        database_endpoint:
          properties:
            port: { get_input: mysql_port }

interfaces

You are allowed to:

  • override an interface defined in the type and override a given operation.
  • override an interface defined in the type by adding a new operation.
  • add a new interface to the node template.
Edit (pull request)