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

[Chris Lauwers <lauwers@ubicity.com>]

Apologies for the late reply. A couple of observations based on the various points made below:

 

         Iâm not sure I agree that âBring Your Own Orchestratorâ is really the main promise of TOSCA. In fact, I firmly believe that TOSCA very much wants to be a full orchestration language that allows for ânativeâ TOSCA orchestration (itâs actually in the name J ). The main promise of TOSCA is that itâs technology and platform-independent, which (in theory) allows for portable service templates.

         That doesnât mean that in practice TOSCA should be used for all (or even most) orchestration tasks. Because of its technology and platform-independent approach, TOSCA is in fact perfectly positioned to act as an âumbrellaâ orchestrator that uses what I call a âdecompose and delegateâ approach: decompose high-level service descriptors into smaller components, where each of these components could be orchestrator by their own (presumable domain-specific) orchestrators. For example, it would be perfectly natural to âdelegateâ orchestration of parts of a TOSCA service to Kubernetes or to use Ansible for other components.

         However, the decomposition process itself and the coordination between (delegated) orchestration of sub-components is itself an orchestration challenge. TOSCA orchestrators need to deal with that challenge by implementing the necessary orchestration logic.

         For better or for worse, TOSCA implements that orchestration logic by running workflows that call interface operations. Those are features that are core to the language. However, the expectation is that TOSCA orchestrators should be able to generate the necessary workflows automatically from the template. I think the reason we have âimperative workflowsâ is because there are a number of scenarios where creating the âdeclarative workflowsâ automatically is difficult or impossible (e.g. when non-standards Interface types are used). We should try to address those shortcomings as Calin suggested.

         The main problem I have with imperative workflows in TOSCA is not that they exist, but rather that there doesnât seem to be a good way to integrate these workflows in the TOSCA paradigm. Iâll try (again) to explain my concern during our meeting on Tuesday J

 

Thanks,

 

Chris

 

 

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Tal Liron
Sent: Monday, July 15, 2019 7:16 AM
To: Calin Curescu <calin.curescu@ericsson.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Groups - TOSCA Imperative Workflows supporting custom workflow language uploaded

 

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?