OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[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 😊

 

  • When I referred to a ârealâ simple profile, I meant to talk exclusively about the language specification, not about the type system. When the Simple Profile was first introduced, the word âSimpleâ was meant to imply that the YAML specification would be âsimplerâ to use (than XML) by template designers. Of course, one could have also assumed that the YAML spec would be a âsimpler version of the specâ (i.e. with less features than the XML spec), which clearly wasnât the case.
  • At the same time, weâve started to use the word âProfileâ to mean âa collection of domain-specific typesâ, and the âSimple Profileâ refers to the built-in, normative types that are supposed to be âunderstoodâ by all TOSCA orchestrators.

 

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:

 

  • A âbaseâ spec that focuses primarily on the modeling aspects of TOSCA
  • An âorchestrationâ enhancement that adds support for workflows etc.

 

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
Sent: Wednesday, July 31, 2019 10:05 AM
To: tosca@lists.oasis-open.org
Subject: Re: [tosca] Groups - TOSCA Imperative Workflows supporting custom workflow language uploaded

 

On Wed, Jul 24, 2019 at 12:35 PM Chris Lauwers <lauwers@ubicity.com> wrote:

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.

 

Thatâs a reasonable suggestion that should be considered and discussed in the TC meetings. Letâs plan on putting this on the agenda for one of our future meetings. This could lead to a ârealâ distinction between a full spec and a âsimple profileâ.

 

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]