Hi Peter,
I’m not sure that the “identity issue” is difficult to solve.
- The question is about how to uniquely identify “nodes representations” that are created from a specific node template
and that are managed by a TOSCS orchestrator. Identifying “node implementations” in the external world is obviously domain/implementation-specific, and outside of the scope of the TOSCA language (although very much in-scope for TOSCA type definitions/TOSCA
profiles)
- If we don’t support multiplicity of “node representations” (i.e. we only support the creation of exactly one “node
representation” for each “node template”, then there is not issue. An orchestrator could just use the node template name as the node representation ID. Each node template name will then uniquely identify a specific “node representation” within a specific “service
topology” context.
- Of course, I believe we have all come to the conclusion that it would be very useful to somehow allow the creation
of multiple “node representations” from the same node template. This introduces a new “unique ID” challenge since an orchestrator can no longer use a single node template name to uniquely identify individual node representations created from the same node
template.
- Tal has proposed a solution that uses “templated” node template names. While that could work, I believe that Tal’s
approach significantly reduces the “readability” of the TOSCA service template. The use of YAML was motivated by the need to make TOSCA templates easy to read and easy to author by humans (as opposed to computers). We should stick to simple names if we want
to keep TOSCA easy to use. I’m also worried about setting a precedent that gets us on a slippery slope. If we allow templated node template names, will users ask for templated type names next? I strongly believe we should avoid going down this path.
- In my implementation, I use a much simpler approach.
- Node templates that can be used to create multiple node representations use an “occurrences” keyword (in exactly
the same way as the “occurrences” keyword is used for requirements that support the creation of multiple relationships). The value of the “occurrences” keyword is generally expected to be provided as an input value at orchestration time.
- For node templates that support multiple “occurrences”, each node representation created from that node template
is assigned a unique index, which can be retrieved using the OCCUR_INDEX built-in keyword (similar to the SELF, SOURCE, TARGET, etc. keywords). The OCCUR_INDEX never changes during the lifecycle of a node and is never re-used for other nodes.
- That index is also used to create a unique “node representation” name using the “node_template_name:OCCUR_INDEX”
pattern.
- During the initial orchestration of the service, the OCCUR_INDEX for each node is sequentially allocated, and the
index is also used to retrieve inputs from a list of INPUT values (using syntax such as the following:
properties:
name: { get_input: [ locations, OCCUR_INDEX, name ] }
- That index is also used to create a unique “node representation” name using the “node_template_name:OCCUR_INDEX”
pattern. This allows each node representation to be uniquely identified (e.g. as a target of a relationship, as an entity to be substituted, as a node for which the properties need to be used in a node filter, etc.). With this approach, node representation
names adhere to a TOSCA standard rather than being arbitrarily configurable by a service designer using runtime data.
- Update scenarios are handled as follows:
i. Services are updated by providing updated sets of input values
ii. For input values that apply to a specific node representation, the OCCUR_INDEX of that node representation
must be provided as part of the input values record.
iii. For input values that need to result in the creation of a new node representation, no OCCUR_INDEX is specified.
The absence of an OCCUR_INDEX signals to the orchestrator that a new node representation much be created and a new OCCUR_INDEX must be allocated.
- The main challenge with this approach is how to “delete” node representations. In my implementation, I actually never
really delete representations, I only mark them (using a state attribute) as “terminated” or “deleted”, so the Update action could be used to specify that a specific node representation must be moved to the “deleted” state.
- By the way, I’m using the same approach (i.e. the “template_name:OCCUR_INDEX” strategy) to uniquely identify relationships
that were created from the same requirements. Just as we need to be able to uniquely identify node representations, we also need to be able to uniquely identify relationship representations.
Hopefully this illustrates that the “multiple representations” scenario isn’t really that difficult to support.
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 16th. 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