Greetings, I would just like to voice an agreement with the idea that there would be a core specification that covers the basics, possibly includes the essential normative types, and then have a set of extensions or add-ons or enhancements or DLCs to complement them for the target domains and use cases. The goal wouldn t be that anyone then makes their own variant of an orchestrator that does a thing differently than another orchestrator does the same thing. What it would do is to release the implementors from the burden to comply with the bulk of the specifications where only a small subset would actually be used. As for the use of workflows for modifying the instance model, I have not yet been able to delve into this proposal to form an opinion. But I come from the group that is very much interested in implementing an orchestrator that is capable of doing that. I expect that in the upcoming revived ad hoc on emergent computation we ll have a set of use cases that we ll be able to explore various solutions and proposals against. That ll bring the world of edge computing, IoT, serverless the use cases where I believe Kubernetes&co. don t help. I share the feeling that I believe Chris said yesterday, that TOSCA already brings so much on the table that there is all the potential for solving this. Best regards, Matej Matej ArtaÄ, Ph.D. / Project Manager XLAB d.o.o. / Pot za Brdom 100 / SI - 1000 Ljubljana / Slovenia tel.+386 40 556 755 / i nfo @xlab.si /
www.x lab .si Project Manager, Platform and Systems Orchestration Member of OASIS TOSCA Standard Technical Committee Member of steampunk.si Google Drive / Linkedin / Twitter From:
tosca@lists.oasis-open.org <
tosca@lists.oasis-open.org> On Behalf Of Tal Liron Sent: Tuesday, August 6, 2019 4:28 PM To: Chris Lauwers <
lauwers@ubicity.com> Cc:
tosca@lists.oasis-open.org Subject: Re: [tosca] Groups - TOSCA Imperative Workflows supporting custom workflow language uploaded On Thu, Aug 1, 2019 at 8:47 PM Chris Lauwers <
lauwers@ubicity.com > wrote: 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. I would say that it should not be an "extension", but really a separate spec. We can call it the "TOSCA Orchestration Language" or similar. Maybe it wouldn't have "TOSCA" in it at all. Ideally it should be a separate file entirely, perhaps one per workflow. So, for example, a CSAR file can include one topology and several workflow artifacts. I remain skeptical that anyone would ever create such an orchestrator -- the market is full of mature orchestrators and it's hard for me to see what would be so attractive about a new one. I think we should focus on making TOSCA consumable by popular, actually-existing orchestrators. 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. OK, so what can we do to fix this? This bugs me *a lot* -- I continue to insist that the very poor quality of these basic types, and the unrealistic expectation that they could ever be used to "write once, deploy everywhere", will continue to hurt TOSCA adoption. Can we make this separation -- language spec, basic types spec -- for TOSCA 1.3? What about TOSCA 2.0?