RE: [tosca] Operation implementations

[Chris Lauwers <lauwers@ubicity.com>]

Hi Adam, my understanding is actually slightly different:

 

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

 

My understanding is to do the equivalent in formal TOSCA you'd define an artifact named "ansible" that invokes the ansible executable and pass it an input parameter the name of a file like "my_operation_playbook.yaml" that is specific to that operation. 

 

Yes, one would create a file called âmy_operation_playbook.yamlâ and define a TOSCA artifact for that file. The TOSCA artifact would define âAnsibleâ as its type (or whatever artifact type definition you use to represent Ansible playbooks), and its âfileâ keyword would point to the location of the âmy_operation_playbook.yamlâ file.

 

However, that (TOSCA) artifact would then be used as the primary implementation for the operation rather than as an operation input. When the orchestrator âcallsâ the operation, it would pass the âmy_operation_playbook.yamlâ to the Artifact Processor (or Configurator in your system) for Ansible artifact types, and this processor would invoke the ansible software to run the playbook.

 

The âinputsâ in the operation are intended to feed service-specific values into the Ansible playbook. If I remember correctly, Ansible uses Jinja2 templating for this purpose, so we need to define how TOSCA input values are used as Jinja2 template values in a somewhat âstandardizedâ way.

 

My implementation supports that behavior but for convenient and expressiveness it as has an extension that allows you to refer to global artifacts like "Ansible" or "Terraform" and those artifacts (through a plugin interface I call "configurator") have the smarts to interpret the inputs, in this case to save the contents of the input parameter as the playbook file.

 

Technically, these are not the artifacts but rather the artifact processors. And yes, the artifact processors need a way to interpret input values and pass them to the artifacts themselves, which are the actual playbooks.

 

But conceptually it's essentially the same as the TOSCA spec, unless I'm misinterpreting it?

 

Yes, the same concepts but used slightly differently.

 

thanks,

Adam 

 

Chris

 

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

Hi Adam,

 

From the email below and from your presentation earlier today, it looks like your implementation diverges from the TOSCA spec in a couple of interesting ways:

 

1.       You make extensive use of inline definitions of the content of the artifacts. For example, you have inline ansible playbooks and inline terraform scripts. I donât believe the current spec anticipates this, although I think this is a good idea and I would be in favor of adding this to the spec.

2.       Your interpretation of the intent of various keywords is different from mine. From the examples below, it looks like youâre doing the following:

a.       Youâre using the âimplementationâ keyword to specify the type of the artifact

b.       Youâre using the âinputsâ keyword primarily to provide the artifact content directly

Iâd love to have a discussion to explore if we can come up with a standardized way of using these keywords across multiple implementations.

 

Thanks,

 

Chris