RE: [tosca] Operation implementations

[Chris Lauwers <lauwers@ubicity.com>]

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:
1. Youâre using the âimplementationâ keyword to specify the type of the artifact
2. 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

 

From: adam souzis <adam@souzis.com>
Sent: Monday, August 23, 2021 12:43 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Operation implementations

 

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

 

 

 

 

á