[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] RE: updated operational model
|
Hi Calin, I concur totally with what you propose. I am sure that several of us have actually implemented something like this, and for me it works nicely. I am, however, noting that some members object strongly to the idea of a âdependency graphâ driving orchestration. Deriving a dependency graph from Relationships is, as far as I am aware, not part of the our
TOSCA standardization. So this would be completely up to the profiles to define. The ETSI standard does define how a template can refer to a previous/subsequent version of itself, although the way it is done there is perhaps not the best design. Peter From: Calin Curescu [mailto:calin.curescu@ericsson.com]
Hi Peter, Some answers/opinions inline
😊. BR/C From: <tosca@lists.oasis-open.org> on behalf of "Bruun, Peter Michael (CMS RnD Orchestration)"
<peter-michael.bruun@hpe.com> 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. [CC] I think it is assumed that there is a âModificationâ box analogous to the âActivationâ box for any day n updates. 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. [CC] I think it is assumed that there is a âModificationâ box (we should draw that explicitly though). 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. [CC] I donât think it is the assumption. 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. [CC] I think that only the case where inputs are changed is depicted, but there is no problem to cover also changes in the template i.e. âupgradesâ. I think that the âModificationâ box mentioned above is allowing
the Operational model to cope with that with no problem. Please also see attached a simple model on how this can be done without complete teardown and re-creation. 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). [CC] The attached depiction uses the delta-model you mention above. I think itâs definitely feasible using some simple rules. 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]