[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Operation implementations
Thanks Tal, comments inline: From: Tal Liron <tliron@redhat.com>
On Wed, Sep 8, 2021 at 1:08 PM Chris Lauwers <lauwers@ubicity.com> wrote:
You are making some assumptions here:
If the orchestrator has built-in support for making gRPC calls, then arguable you donât need to specify an operation implementation, and you wonât need an artifact. All you need is operation inputs at that point.
In this scenario, the artifact would consist of some code that knows how to communicate with Ansible Tower (e.g. a shell script) and the name of the playbook would be specified as an input value to that artifact.
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. Again, in that case you never need to supply âoperation implementationsâ (since youâre not allowed to provide those anyway). All you can specify is operation inputs. I donât believe that this argues against
the use of artifacts as operation implementations. Thanks, Chris |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]