Skip to the content.


Introducing the cloud topology (“clou” + “t”) representation language, which is, simply put, a straightforward and rather generic graph database stored as “agnostic raw data”, in YAML, JSON, XML, or CBOR. By default it will be in YAML.

Clout functions as the intermediary format for your deployments. As an analogy, consider a program written in the C language. First, you must compile the C source into machine code for your hardware architecture. Then, you link the compiled object, together with various libraries, into a deployable executable for a specific target platform. Clout is the compiled object in this analogy.

If you only care about the final result then you won’t see the Clout at all. However, the decoupling allows for a more powerful toolchain. For example, some tools might change your Clout after the initial compilation (to scale out, to optimize, to add platform hooks, debugging features, etc.) and then you just need to “re-link” in order to update your deployment. This can happen without requiring you to update your original source design. It may also possible to “de-compile” some cloud deployments so that you can generate a Clout without any TOSCA “source code”.

Design Principles

Clout is essentially a big, unopinionated, implementation-specific dump of vertexes and the edges between them with un-typed, non-validated properties.

In itself Clout is an unremarkable format. Think of it as a way to gather various deployment specifications for disparate technologies in one place while allowing for the relationships (edges) between entities to be specified and annotated. That’s the topology.

Clout is not supposed to be human-readable or human-manageable. The idea is to use tools (Clout frontends and processors) to deal with its complexity. For example, with Puccini you can use just a little bit of TOSCA to generate a single big Clout file that describes a complex Kubernetes service mesh.

Rule #1 of Clout is that everything and the kitchen sink should be in one Clout file. Really, anything goes: specifications, configurations, metadata, annotations, source code, documentation, and even text-encoded binaries. (The only exception might be that security certificates and keys are best stored in a separate vault.)


Orchestrators may choose to store Clout opaquely, as is, in a key-value database or filesystem. This could work well because cloud deployments change infrequently: often all that’s needed is to retrieve a Clout, parse and lookup data, and possibly update a TOSCA attribute and store it again. Iterating many Clouts in sequence this way could be done quickly enough even for large environments. Simple solutions are often best.

That said, it could also make sense to store Clout data in a graph database. This would allow for sophisticated queries, using languages such GraphQL and Gremlin, as well as localized transactional updates. This approach could be especially useful for highly composable and dynamic environments in which Clouts combine together to form larger topologies and even relate to data coming from other systems.

Graph databases are quite diverse in features and Clout is very flexible, so one schema will not fit all. Puccini instead comes with examples: see storing in Neo4j and storing in Dgraph.


Note that all map keys in Clout must be strings. This is in order to ensure widest compatibility with programming languages and implementations.

version (string)

Must be “1.0” to conform with this document.

metadata (map of string to anything)

General metadata for the whole topology. It may include information about which frontend or processor generated the Clout file, a timestamp, etc.

properties (map of string to anything)

General implementation-specific properties for the whole topology.

The difference between metadata and properties is a matter of convention. Generally, properties should be used for data that is implementation-specific while metadata should be used for tooling. It is understood that this distinction might not always be clear and thus you should not treat the two areas differently in terms of state management.

vertexes (map of string to Vertex)

It is very important that you do not treat the keys of this map as data, for example as the unique name of a vertex. If you need a “name” for the vertex, it should be a property within the vertex. The vertex map keys are an internal implementation detail of Clout.

The reason for this is critical to Clout’s intended use. The vertex key is used only as a way to map the topology internally within an instance of Clout. More specifically, it is used for the targetID field in an edge so that the topology can graphed.

But a Clout processor may very well transform a Clout file and modify the topology. This could involve adding new vertexes and edges or moving them around, for example to optimize a topology, to heal a broken implementation, to scale out an overloaded system, etc. In doing so it may regenerate these IDs. These IDs need only be unique to one specific Clout file, not generally.

If you do need to lookup a vertex by, say, its name property, then the correct way to do so is to iterate through all vertexes and look for the first vertex that has that particular name. Indeed, it is reasonable for Clout parsers to entirely hide these IDs from the user and perhaps represent the vertex map as a list.


metadata (map of string to anything)

The convention is that each application will have its own key under metadata. Often you’ll find information here about what kind of vertex this is, e.g. a TOSCA node:

    kind: NodeTemplate
    version: "1.0"

properties (map of string to anything)

Implementation-specific properties for the vertex. For example, a TOSCA NodeTemplate would have these:

artifacts: {}
attributes: {}
capabilities: {}
description: ""
directives: []
interfaces: {}
metadata: {}
name: "my-node-template"
properties: {}
requirements: []
types: {}

edgesOut (list of Edge)

Clout edges are directional, though you may choose to semantically ignore the direction. The edges are stored in the source vertex, which is why this field is named edgesOut.

As a convenience, Clout parsers may very well add an in-memory edgesIn field, which would also be a list of edges, after mapping the targetID fields of all edges to vertexes, or otherwise provide a tool for looking up edges for which a certain vertex is a target.


metadata (map of string to anything)

Often you’ll find information here about what kind of edge this is, e.g. a TOSCA relationship:

    kind: Relationship
    version: "1.0"

properties (map of string to anything)

Implementation-specific properties for the edge, e.g. for a TOSCA relationship:

attributes: {}
capability: "socket"
description: ""
interfaces: {}
name: "plug"
properties: {}
types: {}

targetID (string)

The key in the vertexes map to which this edge is the target.

Note that there is no need for a sourceID because the edge is already located in the edgesOut field of its source vertex. Clout parsers may very well add such a field for convenience.

Also, Clout parsers may do the ID lookup internally, provide direct access to the source and target vertexes, and hide the targetID field.


A common feature in many Clout use cases is the inclusion of values that are meant to be “coerced” at runtime. Coercion could include evaluating an expression, calling a function, testing for validity of the value by applying constraints, etc.

Clout does not enforce a notation for such coercible values, however we do suggest a convention. Puccini comes with tools to help you parse according to this notation and to perform coercion using JavaScript.

The convention is recursive and assumes that each value is a map with one and only one of the following fields:

All coercibles may also have the following optional fields:

If the value of $value is itself a map, that map may have following optional fields:

$list coercibles may also have the following optional fields:

$map coercibles may also have the following optional fields:

The value of $functionCall is a map with the following required fields:

Additionally, it may have the follow optional fields (for debugging information):

The $information is a map with the following optional fields:

The “type information” mentioned above is a map with the following optional fields:

Example (generated from this TOSCA example):

    - $key:
          name: tosca.function.concat
            - $value: recip
            - $value: ient
          path: topology_template.node_templates["data"].properties["lowercase_string_map"]["concat:¶  - recip¶  - ient"]
          url: file:examples/tosca/data-types.yaml
          row: 188
          column: 9
      $value: Puccini
    - $key:
        $value: greeting
      $value: Hello
    - $functionCall:
        name: tosca.constraint.pattern
          - $value: '[a-z]*'
        path: topology_template.node_templates["data"].properties["lowercase_string_map"]
        url: file:examples/tosca/data-types.yaml
        row: 188
        column: 9
      name: map
      name: LowerCase
      description: Lowercase string
      name: string