RE: [tosca] Groups - TOSCA Language Ad-Hoc WG 2021-02-09.docx uploaded

Thanks Peter. Would you mind discussing these questions during Tuesday’s Ad-Hoc meeting?

Thanks,

Chris

From: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>
Sent: Thursday, February 11, 2021 7:58 AM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: RE: [tosca] Groups - TOSCA Language Ad-Hoc WG 2021-02-09.docx uploaded

Hi Chris and all,

Concerning multiplicity and day-2 scenarios where multiplicities are modified (e.g. by adding Sites to a VPN), there are some questions that I think we need to think about:

In a day-2 scenario we modify nodes and relationships that already exist in the Node Representation Graph as the result of a previous deployment.

First question: How are nodes in that graph identified?

This is important because when you make a change, some of the nodes in the graph should remain “the same”, while others are modified/deleted. But we cannot even begin to formulate this unless we know what “the same” means. So identity of nodes becomes critical. In a day-1 deployment, there is no such concern, and hence the problem has been avoided

One way to do this is that the actual number is decided by the number of elements in an input-list, as we discussed. If there are multiple inputs for a given node (or substitution?) then putting each one in a separate list is obviously bad, and so, as you mention, you do that by using a list of “records” – i.e. instances of a type with multiple values.

So far so good – but one way of identifying nodes created in the Node Representation Graph in this way would be by their respective indices in that input-list. I mentioned, that that is a poor solution because it becomes unwieldy to delete one node in the beginning of the list – the identity of all remaining nodes would then shift, since the index would shift. Seen from the Orchestrator’s perspective, if index defines identity, the change will be:

The node with the highest index is deleted
All other nodes, i, down to the deleted index will get the inputs/properties that previously belonged to the node with index i+1.

The orchestrator would then have to invoke a huge number of changes on the Platform in order to effectuate all these modifications of existing nodes.

Second question: How do we specify identity in the language?

Until now, it seem to me that the TOSCA language has not had to deal with the issue of identity. But in the light of the above, I don’t think that is a tenable position – except for those who do day-1 orchestration only.

One solution could be to designate one (or more) fields of a NodeType as its “key” (may ring too much of database for some) or identification. This would have to be a language feature. Alternatively, we could just define a magical identity-field – like “id”.

Other ideas?

Best regards,

Peter

P.S. I won’t be able to attend on Tuesday 16^th. Sorry.

P.P.S. For some reason the lists.oasis-open.org distribution still bounces for me – please distribute as you see fit.

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Chris Lauwers
Sent: 10. februar 2021 19:03
To: tosca@lists.oasis-open.org
Subject: [tosca] Groups - TOSCA Language Ad-Hoc WG 2021-02-09.docx uploaded

Document Name: TOSCA Language Ad-Hoc WG 2021-02-09.docx

No description provided.
Download Latest Revision
Public Download Link

Submitter: Chris Lauwers
Group: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
Folder: Meeting Notes
Date submitted: 2021-02-10 10:02:12

tosca message