Re: [tosca] Operation implementations

[adam souzis <adam@souzis.com>]

Hi Chris,Â

As you requested, here are a couple of operation implementations that are not shell scripts, adapted from Unfurl's unit tests that exercise its built-in support for Terraform and Ansible. There are many limitations to just invoking those tools on the command line and deeper integration enables a better user experience (for example reduces fragile and redundant configuration, better reporting and error handling, etc):

Âimplementation: Terraform
Âinputs:
  tfvars: # defines Terraform variables
   tag: test
  main: |
   terraform {
    required_version = ">= 0.12.26"
   }

   variable "tag" {
    type    Â= string
   }

   output "tag" {
    value = "Hello, ${var.tag}!"
   }
 outputs: # maps terraform output to TOSCA output
  tag: tag

Âimplementation: Ansible
Âinputs:
  playbook: # inline playbook with access to TOSCA functions
    - set_fact:
      fact1: "{{ SELF.testProp }}"
    - name: Hello
     command: echo "{{hostvars['localhost'].test}}"
Âoutputs: # maps ansible facts to TOSCA output
  fact1: fact1

Some other possible requirements that are hard to fulfill with a simple shell interface:

- error and state handing

- handling asynchronous or long-running operations (that might even be blocked on manual approval)

- need to participate in the deployment plan

- updates to the instance graph and instance attributes that aren't simple one-to-one mappings

Cheers,

Adam

On Tue, Aug 17, 2021 at 2:59 PM Chris Lauwers <lauwers@ubicity.com> wrote:

If we want to get a point where it is possible to create portable service definitions in TOSCA, we need to make sure that we clearly define the âmembraneâ between the TOSCA orchestrator and the external world. This membrane currently consists of âoperation implementationsâ and the information needed by those operation implementations.

Â

During this weekâs TOSCA Language Ad-Hoc meeting, there were at least three different viewpoints expressed about how operation implementations can be defined in TOSCA:

Â

1. Operation implementations are artifacts. Each artifact type is âexecutedâ by an artifact processor that knows how to handle artifacts of that type. This is the mechanism that was prescribed in v1.3
2. Operation implementations can be arbitrary strings. Some implementations do not need to be provided by a file. Instead, a string may be sufficient (e.g., a URL).
3. Operation implementations are arbitrary YAML. In order to allow for validation, Tal has suggested introducing an Operation Type against which this YAML can be validated.

We should explore all three of these viewpoints. One way to do this is to work through specific examples where the best way (or only way) to provide the operation implementation is through one of these three options.

During the meeting, the following use cases were mentioned:

Â

• âDeployingâ a file into a specific directory (presumably on some remote âhostâ)
• Running a shell script

o Within the Orchestrator execution environment

o One a remote âhostâ

• Running a Python script

o A *.py file

o A python egg

o How to deal with virtual environments?

o Best way to deal with dependencies?

• Running Java code

o A .java file

o A jar file

• Ansible playbook

o Using Ansible

o Using Ansible Tower

• Running Cloudify workflows (where the workflow is identified by name)
• Making a REST call
• Making a NETCONF call
• Starting a VM using a VM Image
• Running a container using a Container image

o Using plain Docker (or some other container mgmt. system)

o Using Kubernetes (or some other orchestration system)

• Helm charts
• Â

For each of these use cases, it would be helpful to:

1. Provide an example snippet of TOSCA code
2. Explain how an orchestrator is expected to process this code.

Please contribute when you have a chance. If we get enough of these, Iâll try to create a spot for them in our public github repository.

Â

Thanks,

Â

Chris

Â

Â

Â

Â

á