Support operation_host on operations of NodeTypes and RelationshipTypes

[loicalbertin]

Work In Progress (discussion/feedback needed)

Rational

As you may know we are working on Yorc on supporting operations executed on the orchestrator's host (see ystia/yorc#22 & ystia/yorc-a4c-plugin#14).

Currently we do it by setting a operation_host parameter to ORCHESTRATOR on a workflow step under conditions using a topology modifer. But we think that it will be very interesting to allow a component creator to tag by himself that he is expecting an operation he implemented to be executed on the orchestrator's host

This PR currently only handles the parsing of operation_host but I think we can do more especially on the relationship with operation_host on workflows steps.

DSL support

As you know Alien does not strictly follow the TOSCA specification on operations & implementation

Basically an operation should looks like

create:
  inputs:
    myinput: { get_property: [SELF, something] }
  implementation:
    primary: scripts/create.sh
    dependencies:
      - scripts/utils.sh
    operation_host: ORCHESTRATOR

In Alien the same operation currently would be

create:
  inputs:
    myinput: { get_property: [SELF, something] }
  implementation: scripts/create.sh
  dependencies:
    - scripts/utils.sh

So to keep it simple my proposal is to add support for the operation_host exactly the same way you did for dependencies. I mean directly on the operation level. So with the operation_host it would look like

create:
  inputs:
    myinput: { get_property: [SELF, something] }
  implementation: scripts/create.sh
  dependencies:
    - scripts/utils.sh
  operation_host: ORCHESTRATOR

That's what it is implemented in this PR.

Open issues

Relationship between operation_host on operation and operation_host on workflow steps

AFAIK operation_host support on workflows steps in Alien is limited to steps involving a call_operation on a relationship to explicit if the operation should be executed on the TARGET or SOURCE side.

So the question is: what should we do if an operation_host set on a workflow step is different from the one set on an operation executed during this step ?

I didn't find any explicit statement on this in the specification, but my point of view is that the workflow step should be preferred as it is more flexible than something defined in a type. And hopefully, we will be able to set in the UI when designing a workflow someday.

But this implies that we should not set it "blindly" to TARGET or SOURCE but we should look if something is defined in the operation and take it into account.

What to you think?

Should we keep trying to guess if an operation should be executed on the orchestrator's host?

Currently in both cloudify & Yorc plugins there is an algorithm that try to guess if an operation should be executed on an existing compute or on the orchestrator's host. Should we keep this or should we require to explicitly mark an operation with an operation_host==ORCHESTRATOR tag?

operation_host==CENTRAL?

You defined a keyword named CENTRAL for operation_host from my understanding it looks like having the same semantic than the ORCHESTRATOR keyword defined in the specification. I don't see any good reason for such a divergence. WDYT?

Thanks for your feedback