Re: [tosca] Operation implementations

[Tal Liron <tliron@redhat.com>]

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

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.

You are making some assumptions here:

1. Such "artifacts" can be separated from the actual work to be done. The code that does gRPC calls might be a client that is embedded into the orchestrator. It might not be something you can separate into its own "file"/

2. Even assuming that such an artifact can be separated (e.g. an Ansible playbook with no dependencies) there is no guarantee that it would be packaged into a CSAR and managed in TOSCA. For example, the playbook might be registered with Ansible Tower. Indeed, a single playbook might be used by many CSARs, so would you really expect it to be packaged in each of them?

Â

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.

You are assuming a generic TOSCA orchestrator like Ubicity. I am assuming that some TOSCA orchestrators would, in fact, never allow you to just "run" a script or a program for security reasons or simply because it's not needed. In these cases all possible operations are managed by the orchestrator itself (again, not separatable into "artifacts") and you just need a way to refer to them in TOSCA. For example, Adam's implementation uses Python class names as opposed to Python files.