[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. 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. 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. 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). 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. Peter From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Chris Lauwers Based on the discussions of the last 2 weeks, I made another attempt at a TOSCA operational model. This version largely keeps the building blocks from the previous versions but tries to organize them based on the different phases in the
service lifecycle. It also attempts to introduce Day 2 aspects. Thanks, Chris |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]