RE: [tosca] Operation implementations

[Chris Lauwers <lauwers@ubicity.com>]

Hi Adam, as I stated in my earlier response to Talâs email, I believe that the âimplementationsâ themselves *ARE* the artifacts. Without an artifact, you do not have an implementation.

 

I think we need to clearly differentiate between the various concepts used in âimplementingâ operations:

 

1. The operations themselves. In my opinion, these only define a âsignatureâ for a south-bound (i.e. plug-in) interface that can be called by the orchestrator.
2. The (plug-in) code that provides the implementation for these south-bound interfaces. My understanding is that these are the actual artifacts.
3. Any âsupportingâ artifacts such as configuration files etc. that might be needed by the âimplementationâ artifacts. Using current syntax, these can either be defined as âdependent artifactsâ or passed as operation inputs (using the get_artifact function). We should have a discussion about whether we need both approach and if so, when to use which one.
4. And finally, since artifacts can be âwrittenâ in any language or use any technology, the orchestrator may need âadapterâ code to âexecuteâ those artifacts. This is what weâre referring to as the âartifact processorâ.

 

Letâs continue the discussion about whether all of these concepts are needed, whether we need any others, how to use consistent naming for them, and how to best support them in the language.

 

Thanks,

 

Chris

 

From: adam souzis <adam@souzis.com>
Sent: Friday, September 3, 2021 11:40 AM
To: Tal Liron <tliron@redhat.com>
Cc: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: Re: [tosca] Operation implementations

 

hi Tal,

 

I think it is important to have concept like this (similarly, operator types) that is separate from artifacts because "artifacts" generally mean something closely tied to the file and as you point out implementation often won't refer to an artifact as a file. I advocated this in the ad hoc you missed a couple of weeks ago -- the main objection seemed to be over the cost of introducing another concept and fundamental type to the spec.

 

 

á

 

On Fri, Sep 3, 2021 at 9:13 AM Tal Liron <tliron@redhat.com> wrote:

On Thu, Sep 2, 2021 at 5:57 PM Chris Lauwers <lauwers@ubicity.com> wrote:

In your email below, you talk about an Executor. At first glance, I interpreted the Executor to be similar to an Artifact Processor or to a Configurator, but after reading this again Iâm not so sure.

Would you mind explaining your concept of an Executor?

 

I am using the term "executor" specifically to generalize the use cases for TOSCA operations: calling a gRPC endpoint, starting a playbook installed on an Ansible Tower instance, launching an AWS Lambda serverless swarm, running a Candice NETCONF configuration micro-workflow, etc., are all examples of operation execution that do not involve artifacts. And even when an artifact (or multiple artifacts) is involved, it's more than just processing the artifact, it's about setting up the execution environment for that artifact, whether it's an ssh connection to somewhere, installing dependencies, verification of Python version. And then during and after execution it might collate results, error logs, profiling information, etc. The "artifact" aspect generally seems like the least important task for the "executor", and indeed often there is no artifact at all.