TOSCA v2 treatment of artefact, repository and nodes in general

[<paul.m.jordan@bt.com>]

I would like to make three inter-related comments:

 

1. Allow get_input on various artefact keynames and on repository.url

As you know, nodes can have a property value defined either at design time or at the time they are instantiated. In the latter case this is by use of the get_input function. Nodes may also include artefacts which may be in repositories. The artefact type, file name, version, etc. and the url value of the repository can be declared at design time as a strings but in the TOSCA v2.0 cds02 it is not possible to define any of these values at instantiation time. I propose that this limitation be removed by allowing use of get_input for these keynames.

The use case for this requirement comes from a TMForum Catalyst project where a communication provider allows a corporate customer to deploy an application on a 5G MEC (Multi-Access Edge Computing) at short notice for a temporary period during a natural disaster. While the capability to deploy will be agreed in advance the precise image version and location of the state data will only be known at activation time.

Allowing these values to be input by an external party does create an additional attack vector and to mitigate this threat the input values should be validated. Therefore the syntax should allow inclusion of a constraint clause on each of the keywords which allow get_input.

 

2. Be explicit on whether all nodes must be capable of instantiation.

I believe that in TOSCA 1.3 there is an implicit assumption that each node in the template must be capable of being deployed by an orchestrator i.e. there is always at least one set of circumstances (due to interface operation, substitution, policy etc.) that would require the orchestrator to create an instance of the node; a node cannot exist in the template for any other reason.

I suggest that TOSCA 2.0 presents an opportunity to explicitly allow TOSCA nodes to be extended via relationship of type ‘extends/extendedBy’ to a node which cannot be instantiated itself, but which adds functionality or information. It may be convenient to give such extension nodes a different name or a directive to distinguish them from the classic node concept. If this proposal is rejected then I would like to see the standard make an explicit statement that all node types must be deployable.

My use case for this proposal is that I would like to extend node definitions to include metric definitions which make use of the TMForum Information Model for metrics. That model contains a powerful, but complex, set or related entities.

To date I have been achieving this by denormalizing the Metric Information Model and representing it as TOSCA data types which can be attached to a node. This has proved restrictive because:

a)The denormalization process means that the information model relationships can only be navigated in one direction once they are in TOSCA.

b) The information model contains relationships between abstract entities, but TOSCA does not allow relationships between abstract datatypes. My resolution to date has been to define relationships between each concrete TOSCA datatype but this is not scalable.

Thus I would prefer to define the metric entities as support nodes in TOSCA. I expect that there are other use cases including a more formal definition of licences and their conditions.

 

3. Generalise Artefact and Repository

If, from item 2, we accept that a deployable node can be extended by some other non-deployable support entity via a particular type of relationship which represents that support, then we can consider that:

1. artefact is an extension of node

and that

2. repository is an extension of  artefact.

Now both artefact and repository are very useful concepts for deploying software and, as you can see from above, I am making use of them, but the concept of V2.0 seems to be to move towards a ‘purer’ definition of nodes and relationships as vertices and edges from graph theory while shifting domain specific concepts to a separate, and non-mandatory, document. If true then there appears to be a case for including artefacts and repositories as second class entities. Their type would be derived from the support node type and in a template they would be linked to deployable nodes via a relationship specifically defined for that purpose (and probably derived from the ‘extends/extendedBy’ relationship type).

 

This feels right to me as doing so would solve the concerns raised in point 1.

 

 

Paul Jordan BT plc