Operation implementations

[Chris Lauwers <lauwers@ubicity.com>]

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