[TOSCA-177] CLOSE - Cardinality for node template - OASIS Technical Committees Issue Tracker

Details

Type: New Feature
Status: Closed
Priority: Major
Resolution: Unresolved
Affects Version/s: None
Fix Version/s: None
Component/s: Profile-YAML
Labels:
None

Proposal:
Hide

Add cardinality keyname / section to a node type.

The cardinality keyname will have a lower_bound and an upper_bound attributes.

Each type can define the cardinality boundaries that are relevant for it.

node_types:
type: tosca.nodes.Compute
derived_from: tosca.nodes.Root
properties:

omitted here for sake of brevity
capabilities:

omitted here for sake of brevity
cardinality:
lower_bound: 1
upper_bound: unbounded

node_templates:
my_server:
type: tosca.nodes.Compute
cardinality:
{ get_input: initial_server_count }
properties:

omitted here for sake of brevity

Some (not all) relationship types should also take cardinality into account.
For example, if SoftwareComponent is HostedOn Compute and the Compute has a cardinality of two - each compute node instance should have a SoftwareComponent node instance.

The cardinality boundaries can also be used to bound a scenario of manual scaling.
Show
Add cardinality keyname / section to a node type. The cardinality keyname will have a lower_bound and an upper_bound attributes. Each type can define the cardinality boundaries that are relevant for it. node_types: type: tosca.nodes.Compute derived_from: tosca.nodes.Root properties: omitted here for sake of brevity capabilities: omitted here for sake of brevity cardinality: lower_bound: 1 upper_bound: unbounded node_templates: my_server: type: tosca.nodes.Compute cardinality: { get_input: initial_server_count } properties: omitted here for sake of brevity Some (not all) relationship types should also take cardinality into account. For example, if SoftwareComponent is HostedOn Compute and the Compute has a cardinality of two - each compute node instance should have a SoftwareComponent node instance. The cardinality boundaries can also be used to bound a scenario of manual scaling.
Resolution:

Hide

We have Scaling Capability for horz. scaling and min/max for vertical on Compute node.

Show
We have Scaling Capability for horz. scaling and min/max for vertical on Compute node.

Description

The current YAML profile spec assumes 1:1 ratio between node templates.

The concept of node template cardinality (node instance count) was briefly raised in some discussions and is also addressed in the Plan Portability API

This issue wants to address the initial cardinality of a node template at application deployment phase.
Cardinality changes that are caused by scale operations are out of scope.

Simple use cases that require cardinality are:
1. Application with one instance of a BE compute and two instances of FE compute for HA.
2. One compute that has two instances of the same software component to better utilize CPU usage.

Adding cardinality raises questions about the usage of the get_property / get_attribute functions.

I think that for most common use cases - the current functions are good enough. The common use cases are:

N to 1 ratio
--------------
For example. two FE node instances and one BE node instance - the FE can get info from the BE node instance.
Using the current functions, the BE node will not be able to get info from the FE nodes (1 to N ratio) but this need is unlikely - such reference will probably be used in the relationship between them where the relationship functions are already working on a specific instance.

N to N ratio
--------------
For example, a SoftwareComponent node template is HostedOn a Compute.
The SoftwareComponent can use the get functions to get info from the Compute as every SoftwareComponent node instance will have a Compute node instance.
In an N to N ratio both nodes can get info from one another.

N to M ratio
--------------
For this case the current functions are insufficient but this use case is also unlikely as there will probably be another tier in between that will be used to aggregate the nodes.
For example, if the BE has two node instances (for HA) and the FE also has two node instances - the FE will probably access the BE via a LoadBalancer making this a "N to 1 to M" ratio which is supported by current functions.

CLOSE - Cardinality for node template

Details

Description

Attachments

Activity

People

Dates