[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] RE: updated operational model
|
All, I am aware that I am looking at TOSCA from the âoutsideâ, coming from a different declarative orchestration language. So bear with me, that sometimes I am not
totally into the TOSCA way of seeing things. When I look at figures like these, I try to drill into the semantics of the boxes and arrows. What do the arrows mean? What flow do they indicate? What do different
colors mean. What is the significance in the arrangement of boxes inside/outside/overlapping/left-right? This is called âMereologyâ, by the way. A legend-box would help. First some architectures: 1.
Pure TOSCA orchestrator: The orchestrator was built for TOSCA, and owns the Topology Representations in some physical form 2.
External orchestrator: The TOSCA topologies are input to a non-native orchestrator through which the infrastructure is managed on day 2. This is what
I previously badly referred to as âfire-and-forgetâ â my intention was that, as in slide 1, once the topology has been deployed, there is no continued TOSCA-based management of the service â the rest happens through some non-TOSCA-aware external management
tools. 3.
Stateless orchestrator: The Topology Representations are an abstraction, collected into a single pane of glass from the infrastructure systems. Is this
slide2? 4.
â more? There are scenarios where architecture 3 would work, but in my world it would not, because in that architecture the infrastructure becomes the master for the
topology representations. The problem is that infrastructure configurations (centrifuge model) cannot be pushed atomically to more than one infrastructure manager/controller and infrastructure can fail or be deleted or replaced. In these cases the state held
by the infrastructure can become inconsistent, corrupted or lost, and without an independent Topology Representation, there would be no way to recover. On slide 2+3 you have infrastructure Monitoring and/or topology representations pushing (?) â through policies â updated inputs. It is not clear if those updated
inputs would be a subset of the original inputs or the complete set. Providing the complete set of original inputs from infrastructure/topology representation may be too much to ask of the infrastructure. But if the Updated Service Inputs are only a subset,
then the slides are effectively postulating some storage where information about the original inputs is kept â otherwise there would not be sufficient information to instantiate the topology in the âUpdating/Upgradingâ box. So do we have a âdatabase of inputsâ in a TOSCA architecture? Then there are the double-arrows between the Topology Representations and Activation/Modification. As Tal keeps pointing out, the direction from right to left
of these arrows indicate a flow of attribute-values, and that flow may be asynchronous or synchronous, and the flow can happen by pull or push. For example, in the stateless model 3 above, the
get_attribute could be a pull happening when someone is âlooking through the pane of glassâ. But with synchronous execution, attribute values can also come back as some kind of result-vector, as we have seen in some of our discussions. Sometimes this
is the most convenient mode, sometimes not â so we should not be prescriptive about one mode or the other. Finally, for Monitoring, that is usually some kind of event-mechanism, so a push, and that raises the question how a Monitoring event gets correlated into the
Topology Representation â what does that arrow mean? How does an event find a node in the topology, and what does it do? In our HPE orchestrator, we have solved this in different ways (from TOSCA perspective we are architecture 2 â external orchestrator, but fully declarative like
TOSCA, so no conceptual mismatch): Â
We do have an inventory of currently deployed topologies, including the input parameters Â
We support synchronous execution of artifacts, where a result-vector comes back and sets attributes (parameters) Â
We do have operations and we can pull attribute parameters from the infrastructure or view values in a pane-of-glass mode Â
Nodes in the Topology Representation are seen as resources, and when an artifact is executed, then we pass a resource identifier that an asynchronous
callback can use for passing attribute values back into that node.
o
Timing is âinterestingâ. Asynchronous responses and updates may come with a delay of milliseconds or they may arrive weeks or months later.
o
Asynchronous events may be âunsolicitedâ or may even arrive âtoo earlyâ before artifact execution is complete. This needs to be handled. Â
Monitoring is special in a number of ways â so we need to handle monitoring-events differently from asynchronous activation/modification responses:
o
The rate of arrival of events can be very high â tens of thousands per second. This can overload an orchestrator â particularly if you look at the updated-inputs
loop.
o
Events may toggle rapidly â now it works, now it doesnât, now it does, now it â
o
Events may not be able to uniquely identify a node in the Topology Representation, so some kind of correlation policy needs to be applied
o
Some of the above may be what goes into âECA Policiesâ, but there is also a direct arrow from Monitoring to Topology Representations â what should that
arrow do and would it work? I think the key here is that nodes in the Topology Representations are *resources*. I donât want to imply a specific resource model, but REST and URIs
are obvious possible technologies. Even architecture 3 could support this view. It allows us to talk about how to identify topology representation nodes in all contexts. I am not sure about the Relationships in the Topology Representations. The reason is that in the HPE orchestrator, nodes and relationships are the same (like
everything becomes tables in an RDBMS), so I am not used to having to distinguish. Peter From: Chris Lauwers [mailto:lauwers@ubicity.com]
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 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:
o
âPureâ TOSCA orchestration
o
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>
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]