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)
...