RE: [tosca] RE: updated operational model

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

tosca message