Re: [tosca] Operation implementations

Hi,

I imagine that an artifact processor should be a generic prerequisite that should be available in the environment where the TOSCA orchestrator executes. If an artifact is defined as an implementation of an operation etc. and the orchestrator cannot find it, then the orchestrator should flag an error (either as a runtime or during the validation phase), but not when importing a profile.
Yes, agree. Maybe the fact that an artifact is an implementation should be described in the âdescriptionâ part of the artifact definition, then anybody that could use it would know, so âisImplementationâ may not be that useful.
Yes, regarding the âget_artifactâ it would be more useful to return something like the artifact definition map, thus sending all all the properties. This would avoid also the confustion that if two artifact definition point to the same path, you cannot distinguish them in the get_artifact function.

BR/Calin

From: Chris Lauwers <lauwers@ubicity.com>
Date: Tuesday, 21 September 2021 at 04:56
To: Calin Curescu <calin.curescu@ericsson.com>, adam souzis <adam@souzis.com>, Tal Liron <tliron@redhat.com>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: RE: [tosca] Operation implementations

Hi Calin,

Thanks, this is a nice summary. A couple of comments:

Yes, we could explicitly specify that a specify type of artifact is intended to be used as an implementation. Does that mean that the profile that contains the artifact definition must also include code that can be used as the artifact processor? Will the orchestrator flag an error if no artifact processor is specified?
Alternatively, the mere fact that an artifact is used as an âoperation implementationâ would implicitly specify that this is an âimplementation artifactâ. An orchestrator would then flag an error at orchestration time if there is no âartifact processor/configuratorâ defined for that artifact type
We need to revisit the âget_artifactâ intrinsic function. As defined right now, the âget_artifactâ function returns a string that contains the path name of the artifact, but it doesnât say anything about the context in which that path is valid. More importantly, there is no mechanism for passing artifact properties as part of the âget_artifactâ function, which makes artifact properties useless for artifacts that are not used as operation implementations.

Thanks,

Chris

From: Calin Curescu <calin.curescu@ericsson.com>
Sent: Monday, September 20, 2021 10:30 AM
To: adam souzis <adam@souzis.com>; Tal Liron <tliron@redhat.com>; Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Operation implementations

Hi Adam, Tal, Chris,

How I read the TOSCA specification, is that artifacts are used to designate information that is used/is executed on the outer side of the membrane that is the boundary between the TOSCA scope and the outside world (including the underlying implementations). Thus from the point of view of TOSCA they are âartifactsâ as the TOSCA parser/orchestrator cannot understand or control what and how they do things. I agree that there are 2 classes of artifacts:

artifacts that are used by an âartifact processorâ to execute a specific action, triggered by the TOSCA orchestrator. These I consider implementation artifacts and will represent a script, a code, a specific DSL snippet, that the artifact processor is interpreting, or just-in-time compiling to execute that specific action.

the foremost example here are the artifacts that are âoperationsâ implementations
we have not discussed how policies are implemented in the context of TOSCA yet, but I could envision that such an âimplementationâ artifact could be associated to a policy

artifacts that represent a specific data/information, that is not executed by an artifact processor, but is used as additional external input to another artifact that is an implementation artifact executed by an artifact processor

here for me are VM images, or JPEG pictures, or location data, etc
I do not think that these artifacts should have an intrinsic meaning to TOSCA based on the node type as it was the case in TOSCA 1.2 where the âimageâ artifact was associate to Compute nodes as providing the VM image

I think such VM images should be given as input to the e.g. âcreateâ operation, and its implementation explicitly via the âget_artifactâ function.

So for both these cases I think that name âartifactâ is fitting as for TOSCA they are external objects.

I also think it could be useful for the designer specifying artifacts in a profile to be able to signal if an artifact is intended to be used as an implementation artifact that is implemented by an artifact processor, or not, so we could introduce a new keyword such as âisImplementationâ to signal that this is an artifact that is assumed to be interpreted by an artifact processor to implement a specific action triggered by the TOSCA orchestrator.

BR,

/Calin

From: <tosca@lists.oasis-open.org> on behalf of adam souzis <adam@souzis.com>
Date: Wednesday, 8 September 2021 at 21:48
To: Tal Liron <tliron@redhat.com>
Cc: Chris Lauwers <lauwers@ubicity.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: Re: [tosca] Operation implementations

Yes, an artifact represents a file-like bag of data, and for example, a DevOps deployment process can interact with artifacts in a myriad ways, whether its container images, build process artifacts, artifact registries like JFrog, files destined for a cloud object store like AWS S3, deployment artifacts like Terraform state files, etc. I see its use as representing an implementation as secondary and probably confusing for most users if we overload its meaning to mean any interface to an executable process.

On Wed, Sep 8, 2021 at 11:46 AM Tal Liron <tliron@redhat.com> wrote:

On Wed, Sep 8, 2021 at 1:32 PM Chris Lauwers <lauwers@ubicity.com> wrote:

Hi Tal, would you mind clarifying the two roles that artifact types take on? Based on my understanding, the artifact type is only there to inform the orchestrator which code needs to be executed to âcallâ the artifact (or, using Adamâs terminology, which Configurator to use). Do you see another role for artifact types?

I see many roles for artifacts that have nothing to with operations:

1. Virtual machine images attached to nodes

2. Policy definitions for specialized agents

3. Schemas for special data type validation (e.g. YANG)

...

tosca message