I m attaching another update that shows both:
The split between Design Time and Deployment and Runtime The split between TOSCA Processing and Orchestration .
I also kept a version that shows the Orchestration function in more detail for the case where TOSCA Orchestration is used.
Thanks,
Chris
From: Tal Liron <
tliron@redhat.com>
Sent: Saturday, February 12, 2022 2:35 PM
To: Chris Lauwers <
lauwers@ubicity.com>
Cc: Bruun, Peter Michael (CMS RnD Orchestration) <
peter-michael.bruun@hpe.com>; Calin Curescu <
calin.curescu@ericsson.com>;
tosca@lists.oasis-open.org Subject: Re: [tosca] RE: updated operational model
Chris, without going into a detailed critique, what I see here is a design of a potential orchestrator built on TOSCA. In my opinion, this goes way beyond the scope of what TOSCA should assume. What I keep emphasizing
is that not all TOSCA users intend to build a new orchestrator. We already have mature orchestrators that, for better or for worse, are not going to be discarded, nor do users feel comfortable about adding a higher-level orchestrator to bridge with TOSCA.
And I'm sure that we all want them to participate in the TOSCA ecosystem.
One particular aspect that is a thorn in our discussion is those "normalized representations". The happy compromise we came up with was to put that box in between the processor and the "orchestrator/platform". We all understood that we
were passing the buck here, and that the definition ended up being somewhat amorphous. I'm personally very satisfied with that. One possible implementation of the model is to indeed build a new system that stores these representations in a database (like Ubicity?).
But, when dealing with existing orchestrators and platforms, they have their own mechanisms for resource identification, state management, inventory, lifecycle, etc. Specifically they already have an opinionated methodology for "normalized representations".
The work of integrating those into TOSCA is to find a way to associate them with TOSCA's grammatical features, which were carefully designed to be general purpose. The common-denominator assumption is that every declarative environment will encapsulate "nodes"
with both static and dynamic "properties", and that there are custom-semantic relationships between them (the topology). It won't always be a 1:1 match with TOSCA and indeed it's not expected that every cloud in existence would support all TOSCA features.
For example, artifacts and operations may not have native equivalents everywhere. This is part of the reason I keep saying that a node template can be associated with "zero or more" representations. Sometimes it might be 1:1 (Terraform). Sometimes there might
be multiple subsystems, different ones for different kinds of nodes. Semantics vary. The hope is that TOSCA's grammatical abstractions would make sense for the majority of implementation. I think they do. (Or, they can, unless we bloat the model with too many
assumptions.)
In my own suggestion for an enhancement of the operational model I more modestly added artifacts to the diagram, and also proposed a generic async event model that I don't think favors any specific semantic.
On Sat, Feb 12, 2022 at 1:59 PM Chris Lauwers <
lauwers@ubicity.com > wrote:
Here is another attempt at the diagram based on feedback from Peter and Calin.
Thanks,
Chris
From: Chris Lauwers
Sent: Friday, February 11, 2022 3:12 PM
To: Bruun, Peter Michael (CMS RnD Orchestration) <
peter-michael.bruun@hpe.com >; Calin Curescu <
calin.curescu@ericsson.com >;
tosca@lists.oasis-open.org Subject: RE: [tosca] RE: updated operational model
From: Bruun, Peter Michael (CMS RnD Orchestration) <
peter-michael.bruun@hpe.com >
Sent: Thursday, February 10, 2022 9:15 AM
To: Calin Curescu <
calin.curescu@ericsson.com >; Chris Lauwers <
lauwers@ubicity.com >;
tosca@lists.oasis-open.org Subject: RE: [tosca] RE: updated operational model
Hi Calin,
I concur totally with what you propose. I am sure that several of us have actually implemented something like this, and for me it works nicely.
Yes, my implementation works exactly like that.
I am, however, noting that some members object strongly to the idea of a dependency graph driving orchestration. Deriving a dependency graph from Relationships is, as far as I am aware, not part of the our TOSCA standardization.
So this would be completely up to the profiles to define.
I m not sure I understand this statement. Isn t a TOSCA topology graph (which consists of nodes and relationships) an explicit encoding of the dependencies
between the various components that make up a service? If you re using pure TOSCA orchestration, then this graph absolutely drives orchestration. On the other hand, you could also ignore TOSCA s orchestration features (such as interfaces, operations, notifications,
workflows, etc.) and just hand off the topology representation graph created using TOSCA to a 3 rd -party orchestrator. Tal has now shown us three different examples of this approach (with Kubernetes, Ansible, and Terraform).
The ETSI standard does define how a template can refer to a previous/subsequent version of itself, although the way it is done there is perhaps not the best design.
This statement would suggest that your earlier dependency comment refers to dependencies between different versions of the same template. Am I misunderstanding?
Peter
Thanks,
Chris
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php Attachment: TOSCA Operational Model 2022-02-14.pptx Description: TOSCA Operational Model 2022-02-14.pptx