RE: operation implementations

[Chris Lauwers <lauwers@ubicity.com>]

Thanks Peter, comments in-line

 

From: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>
Sent: Thursday, March 11, 2021 12:49 AM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: RE: operation implementations

 

Hi all,

 

I am sorry, I wasnât able to attend Tuesdayâs meeting in the language group.

 

Section 13.4.2.4 Deploying Dependencies is really a list of open design questions (and a âTODOâ) about how this might work, it is clearly not normative.

 

Yes, if our goal is to enable service templates to be orchestrated by multiple different orchestrators, then Chapter 13 clearly needs a lot of work.

 

As I read the 1.3 specification (please correct me if I am wrong â which is highly likely J), there are two aspects of âprimary/dependent artifactsâ:

1.       Copying the artifact files to a target node including any files that the primary artifact might need to exist locally (like Python packages)

Yes, this assumption is used throughout the 1.3 spec, but this is problematic if TOSCA is supposed to be a language specification only without knowledge of any node types. How does the TOSCA orchestrator know that the âtargetâ node of a relationship is capable of âreceivingâ artifacts, how does the orchestrator know which protocol to use to âdeployâ artifacts to that target, etc. This canât be done without making assumptions about target node types, which weâve been trying to avoid. Thatâs also the reason why in Version 2.0, weâve started to remove operation-related keywords such as âoperation_hostâ, âdeploy_pathâ etc. from the language.

 

2.       Executing the dependent artifacts in the listed order

 

I think this is the only interpretation that makes sense from a âlanguage-onlyâ point of view. But using this interpretation, there really isnât any distinction between the âprimaryâ artifact and the âdependentâ artifact, except that the âprimaryâ artifact must be processed last. Thatâs exactly why I suggested removing the âprimaryâ and âdependenciesâ keywords, and instead just have the âimplementationâ keyword define a single (ordered) list of artifacts.

 

The two concerns seem to be mixed into a single construct with no clear meaning, so you are right that this needs to be fixed.

 

Both concerns seem to be valid, however. Has the first one (~packages, helper-scripts, etc) already been handled by some other mechanism?

 

Not to my knowledge.

 

As for the second concern â automatic execution of primary+dependent artifacts in some order, that opens up a slippery slope of having this as a âmini workflowâ, and it will not be long before someone will ask to have conditions, branches and loops in the list of dependent artifacts.

Yes, and we should resist such requests 😊  The âlist of artifactâ construct should only be used for very simple actions that are hard to do using a single script. For example, I could imagine having an operation implementation that consists of two artifacts: one artifact that must first be copied to a target host, and then a second that âprocessesâ that copied artifact somehow. If there is a need for more complex workflows, then those should be implemented by defining additional interface operations, rather than by defining multiple artifacts on the same operation.

 

The term âdependentâ, by the way, seems to be a misnomer in both cases.

         In case 1. It is the primary artifact that is dependent on the ones in the list, not vice-versa.

         In case 2. there is really no dependency, just a list of artifacts listed in order, where the first one happens to have a special name âprimaryâ (it could just as well be a list of 1 or more artifacts, the first one corresponding to âprimaryâ).

 

My interpretation is that âprimaryâ should come last, since it depends on the dependencies. But this further illustrates the point that the current spec is confusing 😊

 

Peter

 

Chris

 

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Chris Lauwers
Sent: 10. marts 2021 22:10
To: tosca@lists.oasis-open.org
Subject: [tosca] operation implementations

 

When defining operation implementations, TOSCA v1.3 makes a distinction between âprimaryâ and âdependentâ artifacts. Iâm not sure this distinction is useful. I propose that instead, we change operation implementations in v2.0 to take a list of artifacts, where each artifact in the list is processed sequentially.

 

Comments?

 

Thanks,

 

Chris