CLOSE - CSD02 - Compute node scalability should be specified with a Compute node capability

The Compute node can be defined to provide a ScalingCapability which encapsulates the respective horizontal scaling semantics. The question now becomes how to "address" these capability properties versus the "innate" properties of the Compute node type like mem_size. To this point, node properties are addressed in a constraint clause, e.g.: node_templates: my_server: type: tosca.nodes.Compute properties: compute properties disk_size: 10 num_cpus: 2 mem_size: 4 A separate section sibling to properties is needed to specify the capability context by name or by type is needed. With that context the respective capability properties can be accessed. node_templates: my_server: type: tosca.nodes.Compute properties: compute properties disk_size: 10 num_cpus: 2 mem_size: 4 capabilities: scaling: min: 1 max: 8 Note that in general if you can imagine capability properties as ensembles of properties cooperating to specify a specific objective in the context of a node type, you should not see too many properties in a node type since they should end up in capabilities. Given this, the "innate" properties of a node type are just a special capability of the node type and part of a default node type capability semantics. Because of this, we should ask ourselves if we really need to treat node type properties and capability properties differently syntactically. Why not just create a capability name called something like "self" and use a single access syntax. Please note that although I am arguing against using a membership construct for specifying scaling constraints across a node hierarchy, I am not disagreeing that the general idea of supporting the specification of constraints to a group of node templates for other use cases in general.