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] Beyond TOSCA workflows


Chris,

The idea of decomposing a service for sub-orchestrators is good in itself, but I don't see how the current workflow grammar or Calin's fixes do that beyond a very specific paradigm in which it's expected that orchestrators work in "phases" that emit result codes that would determine the next "phase". I'm tempted to call this a "domino paradigm" (clever domino sets also allow for parallel paths!). To get all your orchestrators to work in this way would require an additional system on top -- an "orchestrator of orchestrators" -- and that adds an extra layer of complexity.

In particular I don't see how Kubernetes or other cloud-native orchestration would work with this paradigm.

But really, I don't see the technical necessity. All sub-orchestrators could have access to the entire topology. They can take care of whatever they need to take care of, with each orchestrator handling only what it can handle. In proper cloud-native environments the orchestrators would be able to operate each other.

Beyond that, even if it were useful to somehow configure an "orchestrator of orchestrators", to me this seems entirely out of the responsibility of the architect who designs a TOSCA service template. How is the architect supposed to know how to decompose the service across the various orchestration domains? If there is an orchestrator of orchestrators, it should be doing the decomposition for us.

You seem to have a clear idea of how this would work. Would you mind creating an example for us to discuss? (Feel free to use any workflow grammar you like.)

On Sat, Oct 19, 2019 at 5:54 PM Chris Lauwers <lauwers@ubicity.com> wrote:

Hi Tal,

Â

Iâm not sure that what youâre suggesting/describing is incompatible with the âworkflowâ approach in TOSCA. I look at TOSCA as an end-to-end service description that is not tied to any specific orchestration technology, and as a result can be used for services that combine components in multiple orchestration domains. Using this philosophy, nothing ever gets really orchestrated by TOSCA directly. Instead, TOSCA is responsible for âdecomposingâ a service into sub-components and âdelegatingâ the orchestration of those subcomponents to domain specific orchestrators. Those domain-specific orchestrators could be as simple as bash shells (that run scripts) or as complicated as Kubernetes. Either way, using this approach, something needs to coordinate the âdelegationâ to the different sub-orchestrators. That is the task of a TOSCA orchestrator, and this is where TOSCA workflows come into play. This is also the area where your âdeep integrationâ approach would be very helpful, since the TOSCA spec talks about âartifact processorsâ that handle orchestration of subcomponents by processing artifacts that describe those subcomponents, but the spec is very vague about how the interaction between a TOSCA orchestrator and an artifact processor is supposed to be handled. It would be much more convenient if domain-specific orchestrators could handle TOSCA artifacts. So, there is lots of value in integrating TOSCA more deeply with existing orchestrators, but I think there is also value in keeping orchestration functionality in TOSCA to allow it to coordinate across multiple orchestrators.

Â

Chris



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