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.

tosca message