[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 On Mon, Feb 14, 2022 at 5:28 PM Chris Lauwers <lauwers@ubicity.com> wrote:
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.
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.
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.
Operations are how we respond to events (at least one way we can, there's policy triggers, too). |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]