[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tosca] Beyond TOSCA workflows
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]