RE: updated operational model

[Chris Lauwers <lauwers@ubicity.com>]

Thanks Peter for the detailed response.

 

From: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>
Sent: Thursday, February 10, 2022 1:45 AM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: RE: updated operational model

 

All,

 

My impression is that if there are widely diverging opinions about what TOSCA should be for Day 1, then that is almost approaching consensus, when compared to Day 2.

 

You have Monitoring->Policies feeding into the same Updating Function that Updated Service Inputs feed into, but as drawn, the Day 2 management seems to have no Activation capability â that all belongs to the Day 1 box.

 

It is not clear to me, if that separation was intentional or not.

 

No, that separation was not intentional. I got wrapped around the axle trying to keep Day 2 separate from Day1, but things would be much simpler if we just considered Day 1 a special case of Day2:

• The key point is that all management actions (not just initial provisioning, but also ongoing service management) operate on the âtopology representation graphâ first, and any changes to the representations are then propagated to external implementations. By the way, this is what I understand âmodel-driven managementâ to mean, and the existence of a âservice topology representation graphâ is THE key differentiator of TOSCA vs. other orchestration technologies in my opinion.
• Ideally, I would like to use a generic term such as âpropagationâ or âsynchronizationâ to represent the actions taken by an orchestrator to propagate changes in the representation graph to the external implementation, but I assume people are more comfortable with âtraditionalâ terms such as activation, deactivation, and modification. Iâll update the figure with these additional boxes.

 

If it is intentional, then I have a problem: As I understand TOSCA, you can use the get_input function for defining properties that control substitutions, and that can lead to a modified Topology Representation. But if there is no activation, then the result of the Updated Service Input and ECA Policies will just be that the Topology Representation diverges from the actual External representations. I see no point in having a Topology Representation that has no relevance to the external implementations.

 

Perhaps the intention was, that âUpdatingâ could only affect attributes, not topology, but that conflicts with the current definition of get_input. You would need to restrict the places where that function can be used, and that would impair the language.

No, that was not at all the intention. Hereâs what I had in mind (which I believe is consistent with Calinâs response as well):

• When the system is made aware of a change in the âexternal implementationâ (using TOSCA notifications if youâre using a TOSCA orchestrator), then two things happen:
• Any output values returned by the notification are stored in the corresponding node or relationship attributes (as defined in the attribute mappings)
• Event/condition/action policies for the event associated with the notification are triggered.
• The âactionâ part of the ECA policy would be responsible for âupdatingâ the topology representation graph

As Calin has already stated, an update to a topology representation graph can be accomplished using a combination of the following two mechanisms:

• Providing âupdatedâ values for some or all of the topology template inputs (which could cause requirement fulfillment to be redone and/or substitution to be redone)
• Providing an updated version of the template itself.

Both sets of actions could result in changes to the graph.

 

Iâm fully aware that none of this is actually stated in the TOSCA spec, but Iâm suggesting this as a simple working model for if and when we start discussing Day 2 support in TOSCA in more detail.

 

Another problem is that, as drawn, the Updated Service Inputs are not referring to any Topology Template â so I must assume that they are really inputs to the *same* template as was used as input to the original Provisioning. As concluded by Tal in another thread, users may have Day 2 variability needs that cannot be expressed through inputs to the originally provisioned template. That raises the question if Day 2 should be able to somehow correlate a *different* template (potentially created by some TOSCA generator taking higher level inputs) to a previously provisioned Topology Representation. The Operational Model clearly rules that out, but leaves only the option of complete teardown and re-creation of changed topology representations â and that in many cases leads to unacceptable disruption of the intended functionality as deployed in the External Implementations.

Yes, this is a result of my limited drawing skills. Iâll make another attempt that shows that updates can select templates just like initial deployments can.

 

Alternatively, the Day 1-or-2 dotted boxes should end before the Topology Representations, and there should be some kind of delta-calculation of the before-after Topology Representations, leading to some Activations as an update of the External Implementations to reflect the updated Topology Representations. I heard Tal mention that he doesnât believe this is possible, and I agree that the way TOSCA is defined, it is probably not feasible. (Delta updates work nicely in our system, perhaps because our topology graph is defined in a different way).

Iâm not sure I completely understand your point here. Are you suggesting that provisioning should be part of the service design activity?

 

My conclusion, unfortunately, is that all the above options, derived from the model, will conflict with fundamental decisions in the TOSCA language. Maybe my analysis is wrong â that is a clear possibility, but if I am right, then something has to give â could be the Operational Model, or could be some TOSCA principle.

 

Itâs clear that none of us have the same understanding about either the Operational Model OR any TOSCA principles. My goal with these discussions is to drive us to some sort of consensus so we can make progress on the specification ð

 

Peter

 

Chris