RE: [tosca] Operation implementations

[Chris Lauwers <lauwers@ubicity.com>]

Hi Tal, comments/questions inline:

 

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

 

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.

 

Actually, I believe all of these require artifacts: for all of these examples, there has to be some piece of code that has to be executed. For example, there must be code that places the gRPC call, code that communicates with Ansible Tower to start the playbook, code that communicates with AWS Lambda, etc. These pieces of code arenât part of the TOSCA Orchestrator, and must be provided by the service and/or profile designer instead. In some systems one would call these âplug-insâ. In TOSCA, we call them artifacts. Either way, they are required in order for the Orchestrator to be able to âimplementâ operations.

 

When a service or profile designer supplies the artifact that âimplementsâ an operation,  they must also specify the type of that artifact to allow the TOSCA orchestrator to âcallâ that artifact correctly. Using terminology from the spec, the actual âcallingâ of the artifact is done by the âartifact processorâ (what Adam calls a Configurator in his code). Independent of the language in which the orchestrator is written, the orchestrator might have an artifact processor that knows how to call Python or Java code, how to call Bash scripts, how to process Ansible playbooks, etc.

 

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.

 

Yes, and it should be possible to express all of those using TOSCA.

 

And then during and after execution it might collate results, error logs, profiling information, etc.

 

I image that the Orchestrator would not have visibility into those activities, unless the result of the collation or profiling needs to be reflect back into the service representation, in which case these results should be modeled as operation outputs and stored as attribute values.

 

The "artifact" aspect generally seems like the least important task for the "executor", and indeed often there is no artifact at all.

 

We must have a very different understanding of how operation implementations are supposed to work. How can one execute code without an artifact that contains that code?

 

Thanks,

 

Chris