RE: [tosca] Capacity in TOSCA

Is there any way to specify capacity allocation in a transitive/additive way. For example, assume that I have 2 software applications that each need a certain amount of memory. Iâd like to deploy these applications on a VM that then tries to âallocateâ the sum of the required memory allocations. In the following example, Iâm assuming that the Compute node type itself defines a âhostâ requirement for an IaaS cloud platform (e.g. AWS, Azure, GCP, etc.)

topology_template:

node_templates:

package1:

type: SoftwareApplication

requirements:

- host:

node: compute

allocation:

capabilities:

host:

properties:

mem_size: 2 GB

package2:

type: SoftwareApplication

requirements:

- host:

node: compute

allocation:

capabilities:

host:

properties:

mem_size: 1 GB

compute:

type: Compute

requirements:

- host:

allocation:

capabilities:

host:

properties:

mem_size: <sum of mem_size allocations of my software apps>

Any suggestions for how to do this?

Thanks,

Chris

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Tal Liron
Sent: Monday, January 24, 2022 11:38 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] Capacity in TOSCA

Following up on our last ad hoc, I thought a bit about expressing capacity.

To be clear up front, there are two ways to understand capacity:

1) Design-time capacity. This is about satisfying requirements and creating relationship representations in the graph. So, this feature would allow you to control the shape of the graph. As such it is related to such notions as node/capability filters used when specifying requirements.

2) Run-time capacity. This is, to an extent, outside the scope of TOSCA the language. After all, the fact that the relationship representation exists doesn't say much about how it is implemented in real-world resources. It could, for example, be a pool of connections of various types (primary, redundant, stand-by, etc.) and moreover these can change dynamically as run-time conditions change. For example, a machine low on RAM might reduce its capacity for connections, in which case the orchestrator might need to recreate them (and do the right thing to maintain uptime).

Unfortunately, I think many TOSCA users are unclear about that distinction, or otherwise have a static understanding of capacity that is limited to Day 1. So I think design-time capacity can often be misused and abused. We need to explain this distinction very clearly in the TOSCA spec.

In any case, I have a rather straightforward proposal for how to handle design-time capacity:

DESIGN-TIME CAPACITY

As stated above, the feature is related to node/capability filters. So I suggest adding a new keyword, "allocation", in requirement specifications. Here's a complete example of how it could be used:

capability_types:

Trunk:
properties:
bandwidth:
type: scalar-unit.frequency

node_types:

Gateway:
capabilities:
primary: Trunk
secondary: Trunk

Generator:
requirements:
- egress: Trunk

topology_template:

node_templates:

out1:
type: Gateway
capabilities:
primary:
properties:
bandwidth: 100 GHz
secondary:
properties:
bandwidth: 1 GHz

out2:
type: Gateway
capabilities:
primary:
properties:
bandwidth: 100 MHz
secondary:
properties:
bandwidth: 1 MHz

gen:
type: Generator
requirements:
- egress:
capability: Trunk
node_filter:
capabilities:
- primary:
properties:
- bandwidth: { greater_or_equal: 1 GHz }
allocation:
capabilities:

properties:

bandwidth: 1 MHz

As you can see, next to the "node_filter" there is now a new an "allocation" section, which is syntactically structured similarly to the filters. The way it works is also a bit similar to filters: the number values used in allocation are accumulated and subtracted from the property values while satisfying requirements. So, if that property minus all the allocations leaves a number smaller than the allocation that a requirement specifies, then that capability is essentially "filtered out" and should no longer be considered a candidate for satisfying the requirement. If there are others with available capacity then the algorithm can move on to them.

Also, I don't see any reason why it can't work on the level of node template properties, and not just capability properties. The mechanism is identical (just like it is identical for filters).

RUN-TIME CAPACITY

As I stated above, handling Day 1 and Day 2 run-time capacity is often out of scope for TOSCA. The TOSCA graph represents potentiality, not actuality. However, it might be useful to represent that capacity in some way for TOSCA, via an attribute.

However, if you want to represent the full picture, then you would also want to represent allocation as attributes. Here's an example:

relationship_types:

Connection:
attributes:
links:
type: list
entry_schema: scalar-unit.frequency

capability_types:

Connection:
attributes:
bandwidth:
type: scalar-unit.frequency

node_types:

DB:
capabilities:
connection: Connection

App:
requirements:
- connection:
capability: Connection
relationship: Connection

What's interesting here is that the relationship "links" attribute will give you a count of currently used connections (the size of the list) as well as how much bandwidth each connection is actually using.

Of course it could be an empty list, meaning that there are no current connections, again emphasizing the difference between the design-time relationship (a line on the graph) and the actual implementations (zero or more connections in this case).

How these attributes are filled in depends entirely on the orchestrator.

tosca message