[OASIS Issue Tracker] (TOSCA-177) Cardinality for node template

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/TOSCA-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43658#comment-43658 ] 

Paul Lipton  commented on TOSCA-177:
------------------------------------

Issue was introduced to the TC on July 24th. From the minutes:
SCRIBE Richard Probst (SAP: Next on agenda: newly-introduced issues
SCRIBE Richard Probst (SAP: Moshe explains cardinality issue
SCRIBE Richard Probst (SAP: Need to be able to specify more than 1 instances of a node in a template
SCRIBE Richard Probst (SAP: Use-cases: high availabilty, scalability
SCRIBE Richard Probst (SAP: Solution is to add "cardinality" keyword, with lower bound and upper bound
SCRIBE Richard Probst (SAP: Cardinality > 1 requires a way to describe connectivity relationship between nodes


> Cardinality for node template
> -----------------------------
>
>                 Key: TOSCA-177
>                 URL: https://issues.oasis-open.org/browse/TOSCA-177
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: New Feature
>          Components: Profile-YAML
>            Reporter: Moshe Elisha
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)