cloudsoft.io

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 keynameoperation_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 not supported.

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.