OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

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?

On Mon, Jul 15, 2019 at 5:46 PM Chris Lauwers < lauwers@ubicity.com > wrote: 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. If this is the case, then TOSCA should publish reference implementation code. Right now the spec is riddled with ambiguity. 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. The problem is that the spec does not make workflows optional. If an orchestrator would like to advertise itself as TOSCA-compliant then it would be expected to have full support for TOSCA workflows. This would be a heavy requirement, especially for orchestrator that do not natively have a workflow paradigm. In my view we would do better to reduce the entry requirements for TOSCA, not add to them. Let's put this is the most practical context: Are we expecting the community (or a software startup) to come up with a robust, production-ready TOSCA workflow orchestrator? I would not bet on that horse. I think we are better off complimenting existing orchestration solutions by allowing them to do what they do best, on their own terms.