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.