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


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]