Re: [tosca] Groups - TOSCA Imperative Workflows supporting custom workflow language uploaded

[Tal Liron <tliron@redhat.com>]

Thanks, Calin, I appreciate verbosity.

On Thu, Jul 11, 2019 at 8:35 AM Calin Curescu <calin.curescu@ericsson.com> wrote:

The problem with imperative workflow is that they:

• Are very cumbersome to create since every node needs to be treated in a (at least one) separate step. This is problematic for templates with a large number of nodes.
• Such workflows cannot be reused across different templates since they address nodes by their TOSCA name
• Also, when changing a template, i.e. adding or removing nodes, the workflow definition needs to be manually changed.

I think there are more problems, but I'd focus on one in particular: workflows work at the level of node instances and not node templates. I can think of many real-world situations whereby workflows leave the template far behind. For example, a workflow that adds a loadbalancer in front of an existing node (for scaling, healing, etc.).

I have uploaded a proposal here https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/65601/Specifying%20custom%20declarative%20workflows%20in%20TOSCA%20redux.docx .

This is nicely detailed, Calin, but I doubt I can be very constructive here because I think this whole grammar should be removed from TOSCA. :) I will say that you have the beginnings here of a nice LCM orchestration grammar. I just believe that it's way, way too specific and that you would have to build such an orchestrator from scratch. The more the grammar gets detailed, the harder it is to adapt. Workflow grammar breaks the "Bring Your Own Orchestrator" promise that I believe is part of the spirit of TOSCA.

Â

[CC] I still believe that the TOSCA language should be able to specify workflows (that is, the sequencing and synchronization of operation calls and other activities across the nodes of a topology template) as intended by the designer of the topology template. Otherwise the TOSCA orchestrator would not know of such intent and ordering.

I think the right way to do this is to package implementation-specific orchetrator solutions outside of TOSCA: Ansible playbooks, Kubernetes operators, Mistral artifacts, etc. Integration is all about allowing for the software insight into the TOSCA template and instance model. For example, allow the Ansible playbook to grab a list of hosts from an implemented TOSCA service.

Â

[CC] With respect to that in v1.3 we have added ânotificationsâ in addition to âoperationsâ in an interface to exactly deal with the open loop aspect you mention (and to implement the outside -> in part of the full duplex communication).

Wow, I was entirely unaware of this and it indeed is very close to my "events" suggestion.

So, here's a thought: can we try to think of a way to solve the problem posed by the ETSI requirement using TOSCA notifications?