RE: [tosca-comment] TOSCA v2 treatment of artefact, repository and nodes in general

[Chris Lauwers <lauwers@ubicity.com>]

Hi Paul,

 

Thanks for a very helpful conversation earlier today. As we discussed:

 

• We will look through the service templates in your git repo to identify possible approaches for eliminating the Jinja2 templating step
• We will give more thought to your idea of using node templates for artifacts
• Please forward contact info for the relevant individuals at Incognito who might be interested in participating in TOSCA discussions
• We hope that BT will be interested in sponsoring your individual OASIS membership and we look forward to your participation.

 

Best regards,

 

Chris

 

From: paul.m.jordan@bt.com <paul.m.jordan@bt.com>
Sent: Thursday, October 8, 2020 3:21 AM
To: tliron@redhat.com; Chris Lauwers <lauwers@ubicity.com>
Cc: tosca-comment@lists.oasis-open.org
Subject: RE: [tosca-comment] TOSCA v2 treatment of artefact, repository and nodes in general

 

1. Parameterization of keyname values

I myself independently created the jinja2 workaround which your describe. I donât like it either which is why I raised the comment.

Yes, subject to my availability, I would be happy to join an ad hoc call and am discussing this with Chris.

I see your point that rendering a template so that it is parsable is a separate function to substituting values at run time.

Template rendering, even using environment variables as you suggest, seems to add a whole new stage to TOSCA processors.

At least in my use case, the keyname values would change each time the template was used so, while environment variables are possible, I would need an external program to set them before using the TOSCA template. In which case the overall system complexity is not much lower than the jinja2 workaround.

Your responses are naturally from the viewpoint of a processor author, my viewpoint is that of a template author, template authors tend to consider the orchestrator as a black box and therefore donât distinguish so readily between keyword values and parameter values.

So while I accept that get_input provides a different function I would quite like the solution to work in a similar way, that is values supplied via a command line or gui and validated via constraints set at design time.

 

Perhaps Talâs proposed generalization of my requirement to cover all keyname values goes further than necessary and brings with it unnecessary complexity.

Are there any use cases for parametrizing the value of type? In general I think Iâve only seen that where polymorphism is used, so perhaps type can be excluded from any parameterization solution.

Are there any items which are currently defined as keynames but in fact are not needed for creating the service instance model and could thus be replaced by parameters?

 

The Catalyst project I mention is not (yet) publicly available but the TOSCA files which support it are already on a public github repo https://github.com/5g-ridersonthestorm/gsma-gst/tree/master/tosca . One of the scenarios is a service offered by a communication service provider (CSP) to the supplier of a consumer app. The app supplier places an order for the capability to deploy their app on edge compute devices (MEC) owned and operated by the CSP. Some time later a trigger event occurs which causes the app to actually be deployed on one or MECs.

 

I agree with Chris that validation might not be sufficient to implement security but it is necessary - in the catalyst scenario, at design time the CSP knows how to deploy apps in general, but will not know the image name and repo location until the order is received. There may be many such orders from multiple different app suppliers over time but the CSP would want to use the same TOSCA template to fulfil each of these different service orders.

In this scenario is not possible to know at design time the image checksum but the CSP designer might want to restrict the repo to a whitelist and the image file to a list of supported file formats.  

 

 

2. Is there a concept of a node which cannot be deployed

 

To be clear my concern is describing design-time relationships.

Judging from Talâs reply I donât think I expressed myself well enough. So Iâm tempted to re-phrase â âCan a template contain a node (or node type) which could never be deployed in any circumstances?â, but part Chrisâs reply does answer my question âit is perfectly possible to include node templates in a service template that are not intended to be orchestrated, but are only included to provide additional information to other node templatesâ.

I think is worth stating this explicitly in the document.

My thought was to have an object X which represents things which can be associated with nodes but could never in any circumstances be deployed independently. Object X has the most of the same content as a node. Children of X can also have relationships to other children of X. I too had considered Chrisâs idea that Object X and its children would be marked with a new directive (which Chris dubbed NOOP) to clearly distinguish them.

I will have to try out Talâs idea of using polices and groups and the idea of using âNOOPâ nodes to see how each meets the requirement. Doing so would also serve to better explain my use case to you.

 

Chris also posits a âcreate if not existâ directive. To date I have assumed that that function was implicit in a select directive. (Providing the orchestrator has been provided with enough information to allow it to create the node to be selected.)

 

 

3. Generalise Artefact and Repository

You say âNothing is stopping you from defining your own node types that represent artefactsâ. What you are describing here is very close to what I was proposing. It gives me entities for artefact and repo which have parameters which can be defined with get_input and can be validated against constraints. This seem to me to be a good way to address the outstanding concern you say that the community has with the current artefact definition. The net effect is that artefact and repo are no longer first class concepts like node and relationship which is intuitively true.