Re: [tosca] RE: updated operational model

On Mon, Feb 28, 2022 at 6:26 PM Chris Lauwers <lauwers@ubicity.com> wrote:

I know this is a background activity, but here is another update. This introduces a new âfirstâ slide that removes Day 2 concepts from the picture. In my opinion, this is identical to the operational model we had previously agreed to, although the boxes have been rearranged and a couple of labels have changed.

Â

Thanks,

Â

Chris

Â

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Chris Lauwers
Sent: Tuesday, February 15, 2022 9:57 AM
To: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>; Tal Liron <tliron@redhat.com>
Cc: Calin Curescu <calin.curescu@ericsson.com>; tosca@lists.oasis-open.org
Subject: RE: [tosca] RE: updated operational model

Â

Thanks Peter, youâre articulating more clearly what I intended to say, which is that the operational model does not try to define an architecture, but rather tries to illustrate how and where the various constructs in the language are expected to be processed.

Â

I hope we donât disagree about the following key points:

Â

TOSCA assumes the existence of a âtopology representation graphâ (the old âinstance modelâ) that is created from TOSCA service templates
Most if not all TOSCA implementations expect this âtopology representation graphâ to be persisted.
The âTOSCA representation graphâ can be turned into the actual âimplementationsâ on the external cloud resources using a variety of ways, including:

âPureâ TOSCA orchestration
Delegation to (existing) 3rd party orchestrators

Â

I would also add the following, but these may be more controversial:

Â

There must not be any ambiguity about how a TOSCA representation graph is expected to be created from TOSCA service templates. This part should not be âopen for interpretationâ.
TOSCA workflows, interfaces, operations, and notifications are only relevant in the context of âpure TOSCA orchestrationâ.

Â

I would be very interested in hearing about the various other âorchestration paradigmsâ could be supported using current TOSCA grammar. I actually suspect there arenât that many ð

Â

Thanks,

Â

Chris

Â

Â

From: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>
Sent: Tuesday, February 15, 2022 4:23 AM
To: Tal Liron <tliron@redhat.com>; Chris Lauwers <lauwers@ubicity.com>
Cc: Calin Curescu <calin.curescu@ericsson.com>; tosca@lists.oasis-open.org
Subject: RE: [tosca] RE: updated operational model

Â

I think some confusion comes from the distinction between âTOSCA Orchestrationâ and âTOSCA Orchestratorâ. When we put structure into a box named âTOSCA Orchestrationâ it may appear as if we are designing a âTOSCA Orchestratorâ.

Â

Tal, I previously read you as opposing a database in TOSCA Orchestration, but now I understand that you are just saying, that we should not mandate a database in a TOSCA Orchestrator.

Â

We all agree now that TOSCA Orchestration should have persistent state of the Node Representations â but that persistence just doesnât necessarily belong in one TOSCA Orchestrator. This distinction should cover the cases where persistent state is held by controllers as well as cases with multiple Orchestrators.

Â

Similarly, we should be able to draw an Operational Model showing that Orchestration needs to support Activation, Modification and Monitoring, without implying where those function should go in an Orchestrator.

Â

Since TOSCA does come with interfaces and artifacts (and policies), we do need to somehow indicate where those things may/can go in the Operational Model.

Â

There are several paradigms that can meaningfully fit interfaces and artifacts into Orchestration, but those ways are, it seems, incongruent â there is no one model that covers all the ways that could exist. Stateful/stateless, synchronous/asynchronous, push/pull, â more?

Â

Would we be able to enumerate the valid paradigms, and create an Operational Model variant for each? This would allow template designers to understand what paradigms they are working under.

Â

The variants would clearly not be exclusive, since an actual Orchestrator could support more than one of those paradigms.

Â

But any attempt to draw where interfaces and artifacts fit in the Operational Model based on just one paradigm could easily be misconstrued as excluding other paradigms.

Â

Peter

Â

Â

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Tal Liron
Sent: 15. februar 2022 00:58
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

Â

On Mon, Feb 14, 2022 at 5:28 PM Chris Lauwers <lauwers@ubicity.com> wrote:

Not sure where youâre getting the impression that weâre trying to design an orchestrator. We all share the same goal, which is to design a language. Of course, this language defines orchestration semantics (and has done so since v1.0) that may not be useful for your target applications. In that case, you should feel free to not implement those as Peter suggested.

Â

Your recent additions to the operational model go too far in my opinion. None of them are necessary to make the language coherent. Of course nobody has to implement everything, but then we get back to the TOSCA 1.X problem in which there was a Simple Profile that nobody had to implement but created baggage, misunderstanding, and ultimately ill will. I'll argue for keeping the operational model as minimal as possible.

Â

TOSCA doesnât say anything about where topology representations are expected to be stored. TOSCA just expects them to exist.

Â

It's more than that -- we need to be very careful to not dictate the "how" of their existence. Again, we need to be as minimal as possible in specifying them.

Â

ÂAnd Iâm happy to hear that we not agree that one can create multiple node representations from the same node template.

Â

In the past you insisted that there was a 1:1 correlation between node templates and node representations. Perhaps you meant to emphasize something else at the time in a different context.

Â

Our disagreement arises when we talk about relationships. You want TOSCA to be able to specify the "how" of relationships between node representations. I insist that it's domain-specific and determined by the use case and its semantics. TOSCA's constructs know only about node templates and should not and cannot enforce node and relationship representation semantics. What we can do is create profiles that model these using properties and attributes, with the additional power of being able to model relationship types as first-class citizens. Cardinality, one-to-many/many-to-one, and countless other scenarios are up to the modeler, based on the platform, and not for the TOSCA language to enforce.

Â

We need to revisit this. Operations are not events.

Â

Operations are how we respond to events (at least one way we can, there's policy triggers, too).

tosca message