search

xlab-si / xopera-opera

xOpera orchestrator compliant with TOSCA YAML v1.3 in the making
https://xlab-si.github.io/xopera-docs/
Apache License 2.0
35 stars 14 forks source link

Add support for other TOSCA Implementation Types and automation tools #72

Open anzoman opened 4 years ago

anzoman commented 4 years ago

Description

TOSCA orchestrators give practical meaning to the TOSCA standard by arranging the tasks in order and providing the TOSCA operation actuators that can be executed and can thereby automate the specified tasks. Here we are talking about TOSCA Artifact types:

TOSCA Artifacts Types represent the types of packages and files used by the orchestrator when deploying TOSCA Node or Relationship Types or invoking their interfaces.

Implementation Types: includes those artifacts that represent imperative logic and are used to implement TOSCA Interface operations. These typically include scripting languages such as Bash, Chef and Puppet.

xOpera currently execute TOSCA interface operations with Ansible playbook implementations. But to extend the usage of opera orchestrator and to provide more options we should consider adding the support for other implementation types and automation tools. Some people may see the ugliness in this but at the end opera would be a more dynamic orchestrator which would also be friendly for users that are not so familiar with Ansible or automation tools in general.

Some new possible operation executors might feature:

There might also be some needs to include the support for other scripts and automation tools like: Ruby, Juju, Jenkins, Vagrant. Docker, Terraform and so on.

Steps

In order to add the support for different scripting languages behaviour we would have to implement new TOSCA interface operation executors and put them in /src/opera/executor folder where Ansible executor currently resides.

For the start we could implement the executors that are directly described in TOSCA under tosca.artifacts.Implementation. This would include tosca.artifacts.Implementation.Bash for bash scripts that would contain bash commands which would be executed on the Unix Bash shell and tosca.artifacts.Implementation.Python which would use Python interpreter to execute a Python file that would contain different Python language constructs.

Current behaviour

Right now opera uses Ansible playbooks to trigger and execute TOSCA operations.

Expected results

To be able to use other implementation types for TOSCA operations.

anzoman commented 3 years ago

@cankarm, @sstanovnik we've talked about adding bash/python some time ago and most recently about supporting Terraform here in xOpera CLI or in xOpera SaaS. This issue could be useful for us to determine what do we want to do concerning additional TOSCA actuators (apart from Ansible that is currently our primary automation tool).

sstanovnik commented 3 years ago

Before we get to implementing new executors, we need to define an interface (both semantic and programmatic) on how these executors (or are they called actuators in the standard?) operate. Things that spring to mind:

There are bound to be more, these three are just ones that I keep coming back to when thinking about this. I would also have a generic "executable" executor, which is whatever you want, as long as it's executable. This could, in essence, mean that we support every possible executor out of the box, since a user can just write a wrapper script around any other tool to process inputs and outputs.

anzoman commented 3 years ago

@sstanovnik great, thanks for mentioning all this!

So, do you mean if we support every possible executor, the users would have to write a their own wrapper script? Or should we provide them? Maybe a second option is not even bad if you think from a perspective that for the first option you'd probably have t set up some plugin system for the users, which might be very complex and would take quite some time. Or maybe we can combine both and just support the most popular executors and for the other ones the users would have to do it?