Supported Objects

AMP supports almost all TOSCA objects described in the official OASIS TOSCA Specification 1.3. This section show which objects are currently supported, partially supported or not supported at all and the reason behind each decision. Future versions of AMP may support more TOSCA objects.

Service Template

Service template is the primary document that captures all the definitions. This is packaged with resources (e.g. scripts) in a CSAR (Cloud Service ARchive). The service template defines:

Object	Status	Observations
Service template TOSCA specification version	Supported
Metadata (`metadata`)	Supported	Extra member to provide icon support.
Repositories (`repositories`)	Supported
Artifacts (`artifact_types`)	Supported	Keyname `version` is saved but not used, since the version for an artifact is taken from the bundle it is part of. Keyname `metadata` is saved, but not displayed anywhere in AMP UI.
Description (`description`)	Supported	Conflicts with the description under `topopogy_template` if present.
Data (`data_types`)	Supported	Keynames `key_schema` and `entry_schema` are saved, but not used in in the current version of AMP, since YAML objects such as lists and maps are converted automatically to the proper type; all constraints but `schema` are supported.
Capabilities (`capability_types`)	Not Supported	A few capability types are part of the catalog and they can be used. Developers cannot add new ones in their blueprints, since they require Java code to implement their behaviour.
Interfaces (`interface_types`)	Supported	Added to AMP catalog as `ToscaInterfaces*`.
Relationships (`relationship_types`)	Supported	Keyname `valid_target_types` is not supported. Added to AMP catalog as `ToscaRelationship$<Derivedtype>`.
Nodes (`node_types`)	Supported	Added to AMP catalog as `Entity` types.
Groups (`group_types`)	Not Supported	No use case identified.
Policies (`policies_types`)	Minimally Supported	Policies require extra logic, that must be written in Java.
One or zero topology template (`topology_template`)	Supported	It is also called a deployable.

The objects listed previously are all supported in AMP, fully of partially depending on the use cases identified. A service template is also called a blueprint in AMP, and its contents are described using the YAML structured text format.

In objects listed in the following table, can also appear in a service template and are currently not supported in AMP.

Object	Status	Observations
Imports	Not Supported	Not necessary, since all types are saved in the AMP catalog.
DSL Definitions	Not Supported
Namespace	Not Supported

Service Template TOSCA Specification Version

Currently, AMP supports TOSCA Specification version 1.3, so service template files must start with: tosca_definitions_version: tosca_simple_yaml_1_3.

It is expected if AMP will support future versions of TOSCA, such as 2.0, currently under development for the service template header to be updated to : tosca_definitions_version: tosca_simple_yaml_2_0.

Metadata

The metadata section contains information about the service template - name, author and version. The metadata section can specify any additional information relevant for development and usage of the objects declared in the service template. Most AMP service templates have a metadatada section similar to the one shown below.

metadata:
  template_author: Cloudsoft
  template_name: io.cloudsoft.tosca-tomcat9
  template_version: 1.0.0-SNAPSHOT
  template_icon: classpath://icons/tosca-tomcat9.png
  creation_date: 2020-11-05
  status: final

AMP interprets the template_name value as a bundle identifier when the service template/blueprint contains only non-deployable types. AMP interprets the template_name value as the application name when the blueprint contains only a deployable section (topology_template).

Note: The bundle identifier identifies uniquely a group of types added to the AMP catalog.

AMP introduces the template_icon metadata member, that can be used to attach an image to a bundle when the service template/blueprint contains only non-deployable types. Types in a service template/blueprint can declare their own icon, but if they do not, the bundle icon is inherited. The deployable type (topology_template) inherits the bundle icon.

Interfaces

When declaring an interface type the developer must specify the type it is derived from and provide values for the properties declared in the spec. These properties and their current support in AMP is shown in the table below:

Object	Status	Observations
`derived_from`	Supported	Only types already present in the AMP catalog are accepted.
`version`	Supported	Keyname `version` is saved but not used, since the version for an artifact is taken from the bundle it is part of.
`metadata`	Supported	Keyname `metadata` is saved, but not displayed anywhere in AMP UI.
`description`	Supported
`inputs`	Supported
`operations`	Supported
`notifications`	Not Supported	No use case identified.

Relationships

When declaring a relationship type the developer must specify the type it is derived from and provide values for the properties declared in the spec. These properties and their current support in AMP is shown in the table below:

Object	Status	Observations
`derived_from`	Supported	Only types already present in the AMP catalog are accepted.
`version`	Supported	Keyname `version` is saved but not used, since the version for an artifact is taken from the bundle it is part of.
`metadata`	Supported	Keyname `metadata` is saved, but not displayed anywhere in AMP UI.
`description`	Supported
`properties`	Supported
`attributes`	Supported
`interfaces`	Supported
`valid_target_types`	Supported	The type(s) are saved, but not used in any way.

Nodes

When declaring a node type the developer must specify the type it derives from and provide values for the properties declared in the spec. These properties and their current support in AMP is shown in the table below:

Object	Status	Observations
`derived_from`	Supported	Only types already present in the AMP catalog are accepted.
`version`	Supported	Keyname `version` is saved but not used, since the version for an artifact is taken from the bundle it is part of.
`metadata`	Supported	Keyname `metadata` is saved, but not displayed anywhere in AMP UI.
`description`	Supported
`attributes`	Supported	All keynames are supported but `key_schema` and `entry_schema`. These are saved, but not used in in the current version of AMP, since YAML objects such as lists and maps are converted automatically to the proper type; all constraints but `schema` are supported.
`properties`	Supported	Same as attributes.
`requirements`	Supported
`capabilities`	Supported
`interfaces`	Supported	Interface keyname `notifications` are not supported. For `operations` see next section.
`artifacts`	Supported

Operations

An operation definition defines a named function or procedure that can be bound to an operation implementation. Operations represent concrete behaviour that can be attached to a node or relationship interface to be executed during the lifecycle or triggered manually via effectors.

An operation implementation specifies one or more artifacts (e.g. scripts) to be used as the implementation for an operation in an interface.

Operation definitions are based on the values of four keynames, listed in the table below.

Object	Status	Observations
`description`	Supported
`implementation`	Supported	Implementation keyname `timeout` keyname is not supported; it was deemed unnecessary. Implementation keyname`operation_host` is not supported either, since AMP has other ways of providing the similar behaviour.
`inputs`	Supported
`outputs`	Supported

Topology Template (Deployable)

The topology_template is the deployable part of a service template, it is the part that based on which an orchestrator (in this case AMP) creates a cloud application. The set of key names declaring templates for the application functional (live) parts are listed in the table below:

Object	Status	Observations
`description`	Supported	Conflicts with the description above `topopogy_template` if present.
`inputs`	Supported
`node_templates`	Supported
`relationship_templates`	Supported
`groups`	Supported	Only pre-defined group types (e.g. `brooklyn.tosca.groups.initializer`, `brooklyn.groups.Parent`).
`policies`	Minimally supported
`outputs`	Supported
`substitution_mappings`	Not Supported
`workflows`	Not Supported

Node Templates

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. Node templates are turned into functional (live) parts of an application by an orchestrator, in this case AMP. AMP uses entities to interact and monitor these live application parts.

Object	Status	Observations
`type`	Supported	Any node type from the catalog.
`description`	Supported
`directives`	Not Supported	Specification unclear, deemed unnecessary.
`metadata`	Supported
`properties`	Supported
`attributes`	Supported
`requirements`	Supported
`capabilities`	Supported
`interfaces`	Supported
`artifacts`	Supported
`node_filter`	Not Supported	Keyname `node_filter` for a node is not supported, since AMP can find nodes by their id.
`copy`	Not Supported	Deemed unnecessary.

The requirements keyname is used to declare a list of requirements required to create the node and the relationship between the node being created and its dependencies. The following table lists the keynames and observations for a requirement:

Object	Status	Observations
`node`	Supported	Any node type from the catalog or a node template name in the same service template.
`relationship`	Supported	Any relationship type from the catalog or a relationship template name in the same service template.
`capability`	Supported	Any capability type from the catalog or a capability template name in the same service template.
`node_filter`	Not Supported	Keyname `node_filter` for a requirement is not supported, since AMP can find nodes by their id.
`occurences`	Not Supported	Keyname `occurences` for a requirement is only supported to specify a minimum value of either 0 or 1.

Relationship Templates

A Relationship Template specifies the occurrence of a manageable relationship between node templates as part of an application’s topology model that is defined in a TOSCA Service Template. Relationship template represent the customization on an existing relationship type in the context of a topology template.

Object	Status	Observations
`type`	Supported	Any relationship type from the catalog.
`description`	Supported
`metadata`	Supported
`properties`	Supported
`attributes`	Supported
`interfaces`	Supported
`copy`	Not Supported	Deemed unnecessary.

Normative Data Types

The following table lists the TOSCA normative types AMP supports being used in its blueprints.

Type	Status	Observations
`string`	Supported
`integer`	Supported
`float`	Supported
`boolean`	Supported
`timestamp`	Supported
`version`	Supported
`range`	Supported
`list`	Supported
`map`	Supported
`scalar-unit.size`	Supported
`scalar-unit.frequency`	Supported
`scalar-unit.time`	Supported
`scalar-unit.bitrate`	Not Supported	Planned for next version of AMP.
`tosca.datatypes.Root`	Supported
`tosca.datatypes.json`	Supported	Planned for next version of AMP.
`tosca.datatypes.xml`	Supported	Planned for next version of AMP.
`tosca.datatypes.Credential`	Supported	Supported via Java implementation, properties are just for reference only.
`tosca.datatypes.TimeInterval`	Supported
`tosca.datatypes.network.NetworkInfo`	Supported
`tosca.datatypes.network.PortInfo`	Supported
`tosca.datatypes.network.PortDef`	Supported
`tosca.datatypes.network.PortSpec`	Supported

For information about node, policy, relationships, artifact types check out the main section of this documentation.

DSL Functions

The TOSCA specification declares a minimal set of DSL functions. AMP supports them all except get_artifact which was deemed not necessary, because AMP is smart enough to download remote artifacts by default and get_nodes_of_types which has no relevance without substitution_mapping or node_filter.

Custom TOSCA Types

For convenience and ease of use, AMP provides a few custom types extending the TOSCA normative set. They are part of the default catalog and a brief description is provided below.

io.cloudsoft.depends-on-db - models a relationship between an Apache Tomcat server and a database. This relationship type extends tosca.relationships.DependsOn and the pre_configure_source operation is configured to execute a small script that configures the Apache Tomcat server with the database URL, provided by the target node of this relationship, which is a MySQL or PostgreSQL instance.
tosca-tomcat8-node models an Apache Tomcat v.8 node type. This type extends tosca.nodes.WebServer and declares a dependency on a database node through the needs-db requirement.
tosca-tomcat9-node models an Apache Tomcat v.9 node type. This type extends tosca.nodes.WebServer.
smart-tomcat9-node models an Apache Tomcat v.9 node type. This type extends tosca-tomcat9-node and declares with two properties: db_url and db_driver. These support configuration of a database without requiring a relationship.
io.cloudsoft.smart-tomcat9-node - this is a template type containing a declaration of an Apache Tomcat v.9 node type being hosted on a Compute node. It is decorated with AMP components such as enrichers, policies and initializers that makes it suitable for use as a member in a dynamic cluster.
tosca-postgresql12-node - models a PostgreSQL v.12 node type. This type extends tosca.nodes.Database; properties to configure the database port - app.port and a location where the database install package is downloaded from - postgresql.url are declared.
io.cloudsoft.smart-postgresql-node - this is a template type containing a declaration of a PostgreSQL v.12 node being hosted on a Compute node. It declares a set of outputs that makes it usable together with a dynamic cluster.
io.cloudsoft.cluster-with-postgresql - this is a template type containing a declaration of cluster of Apache Tomcat node and a PostgreSQL database node. The number of Apache Tomcat node nodes is decided based on cpu usage.
tosca-mysql5-node - models a MySQL v.5 node type. This type extends tosca.nodes.Database; properties to configure the database port - app.port and a location where the database install package is downloaded from - mysql.url are declared.
io.cloudsoft.smart-mysql-node - this is a template type containing a declaration of a MySQL v.5 node being hosted on a Compute node. It declares a set of outputs that makes it usable together with a dynamic cluster.
io.cloudsoft.cluster-with-mysql- this is a template type containing a declaration of cluster of Apache Tomcat node and a MySQL database node. The number of Apache Tomcat node nodes is decided based on cpu usage.
tosca-nginx-node - models a Nginx Load Balancer node type. This type extends tosca.nodes.SoftwareComponent; properties to configure the application port - app.port a list of servers managed addr.list are declared.
io.cloudsoft.tosca-autoscaling-and-resiliency contains a single topology type named as the bundle. This type can be used to create nodes in a tosca.entity.DynamicCluster. The topology type is decorated with AMP components such as enrichers, policies and initializers that makes it suitable for use as a member in a dynamic cluster. The number of Apache Tomcat node nodes is decided based on the number of requests per minute.
io.cloudsoft.tosca-amp contains a single type named tosca-amp-node that extends tosca.nodes.SoftwareComponent that models an AMP installation. Although a default URL is configured specifying the location where the AMP package should be downloaded from, at deploy time a URL pointing to the most recent release should be provided as input.
io.cloudsoft.brooklyn.tosca13.tosca-3-tier contains a single topology type named as the bundle. This type can be used to create a 3-tier application consisting of a MySQL database, a dynamic cluster of Apache Tomcat v.9 servers, managed by a Nginx load balancer.
tosca-simple models a simple application secured using Hashicorp Vault. This type extends tosca.nodes.SoftwareComponent and requires a Linux Ubuntu VM as a host.
hello_node models a simple application configured using PowerShell scripts. This type extends tosca.nodes.SoftwareComponent
and requires a Windows VM as a host.

Node: Custom types mentioned in this documentation are designed to be used with Ubuntu 20 locations, unless a different operating system is mentioned in the template or type description.