[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Groups - TOSCA Imperative Workflows supporting custom workflow language uploaded
Hi Tal, Thanks for your response. I agree with your general sentiment, but I believe your email shows we need to get more consistency in our terminology
😊
To avoid any confusion caused by sloppy naming, we decided to name the next version of the specification âTOSCA Version 2.0â and remove any references to âsimpleâ or âprofileâ. To get back to your original question: what I meant to say is that we ought to perhaps consider splitting the language specification itself in two parts:
All of this is independent of how we deal with âprofilesâ. We should have a discussion about whether it makes sense to decouple the language specification from the type system. The fact that TOSCA automatically imports normative types based
on the version of the language has always bugged me a bit. Thanks, Chris From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
On Behalf Of Tal Liron On Wed, Jul 24, 2019 at 12:35 PM Chris Lauwers <lauwers@ubicity.com> wrote:
As someone who thinks that the Simple Profile is a non-starter, I don't know if the distinction would be important. There is no orchestrator that implements everything in TOSCA, definitely not based on the Simple Profile types for any actually
existing cloud platform. I don't know if there ever will be. Yes, TOSCA needs to be a proper *language* specification. But when the spec dictates an orchestration architecture it goes beyond "language". Indeed I believe there's confusion in the industry as to what TOSCA really is and what it means
to be a "TOSCA orchestrator". This confusion does not benefit adoption. I am very much hoping that we would be able to separate the Simple Profile from the language specification itself. Then, orchestrators could come with profiles that make sense for their domains. These profiles could use some or all TOSCA
language features. Some would make use of workflows and interfaces and artifacts and attributes substitution mapping if those features makes sense for the cloud platform, some might not. They would still be compliant with the *language*, and we would all benefit
from that commonality. As an example, in Puccini I'm experimenting with various example profiles that address real-world use cases. Specifically, the Kubernetes/Istio profile provides a nice TOSCA-based alternative to Helm. But, I can't find a use for workflows
in Kubernetes. However, the BPMN profile does allow you to create workflows that can be exported as sub-processes to BPMN middleware. So, it could be possible to import both profiles and allow for a service template that can deploy a complex Kubernetes application,
with a service mesh, and then allow workflow extensions to define the relationship of nodes within the service to a BPMN open loop. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]