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 |
Project Manager, Platform and Systems Orchestration Member of OASIS TOSCA Standard Technical Committee Member of steampunk.si |
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?