OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [tosca] Agenda for Aug. 13 TOSCA Language Ad-Hoc Meeting


Hello Chris,

 

thank you for this summary.

 

  1. I agree that my scenarios are not valid, so I was thinking of shifting it to the operations within the orchestrator. Starting from the assumption that the orchestrator is able to match the new instance model graph with the current one, it is able for each node to tell if it a) disappears, b) newly appears, c) remains but gets a new state in terms of properties, d) is unchanged. So d) is trivial, a) and b) are already handled with the standard interfaces, so that leaves c) to be defined somehow.
  2. Where would a note not being scalable come into play? Perhaps when you set a node template to be of variable instance count, but make another one that is in a relationship with the first one inadvertently scalable as well, even though you shouldn’t have?

 

As for my assumption in point 1, I am aware of the cases where the resolving of requirements is dynamic and things get fuzzy. But in the cases where everything is defined in the service template, there is no such issue.

 

I look forward to further discussing this at the meeting.

 

Best regards,

MAtej

 

Matej Artač, Ph.D. / Project Manager
XLAB d.o.o. / Pot za Brdom 100 / SI - 1000 Ljubljana / Slovenia
tel.+386 40 556 755 / info@xlab.si / www.xlab.si

Project Manager, Platform and Systems Orchestration

Member of OASIS TOSCA Standard Technical Committee

Member of steampunk.si

Google Drive / Linkedin / Twitter

 

 

From: Chris Lauwers <lauwers@ubicity.com>
Sent: Tuesday, August 20, 2019 5:16 AM
To: Matej Artač <matej.artac@xlab.si>; tosca@lists.oasis-open.org
Subject: RE: [tosca] Agenda for Aug. 13 TOSCA Language Ad-Hoc Meeting

 

Hi Matej,

 

Thanks again for writing this up. These perspectives are very helpful. A couple of comments:

 

  1. As we discussed last week, your “update” scenarios may actually result in topology changes after all, since property values may get used in substitution filters, which might cause substitution to get re-evaluated.
  2. Yes, the issue of “variable instance count” is something that needs more discussion. I don’t believe that we should automatically assume that all node templates in a topology template can get instantiated multiple times. In my opinion, we need support in the TOSCA language to indicate whether node templates are scalable or not (i.e. whether they can be instantiated multiple times). I know we currently have a “scalable” capability in the normative type system, but in my opinion this is a gross mis-use of what capabilities are intended for. Let’s discuss on Tuesday if possible.

 

Thanks,

 

Chris

 

From: Matej Artač <matej.artac@xlab.si>
Sent: Tuesday, August 13, 2019 3:58 AM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: RE: [tosca] Agenda for Aug. 13 TOSCA Language Ad-Hoc Meeting

 

Thank you, Chris,

 

if I may write a few things before the meeting, I’d like to say that my group currently has no stake or any use cases that would use imperative/external workflows. So I’m viewing the ‘modifying deployment service instance’ from the use of existing imperative workflows and the ones that future versions of TOSCA might gain.

 

Update, to me, is a process that should not change the topology, but only apply to properties of the nodes in the existing instance model. So there would be no new nodes or relationships after an update. In practice, the orchestrator would run an “update” workflow, just like “deploy” and “undeploy”, and as a payload it would receive a file that would contain a list of node template names and new values of the corresponding properties. TOSCA could then provide an optional set of interfaces with operations to be interwoven, just like those for deploy and undeploy. The interfaces could probably be able to supply the current state before the update as inputs to the operations.

 

There is a special case with the node templates that have a variable instance count. Would an update also be able to increase or decrease the instance counts? Here, I’m not yet sure. I would welcome, however, the suggestions of how to address the use cases where scaling up or down by adding or removing instances of nodes is required.

 

In the upgrade scenario, I’d just focus on the use case where a new service template gets supplied. It is fairly easy for an orchestrator to get the differences between the existing instance model graph and the new one. In the most trivial case, it could then run partial undeploy workflow on the outgoing nodes, and run the deploy workflow on the incoming ones. So this scenario is pretty much doable with the existing profile. But if we present it as a possible direction, there may be a useful extension to the profile to be able to specify that certain node template’s instances should not be upgraded without the whole thing being torn down entirely first.

 

I think that this approach would solve many of the use cases, where orchestration of change is both required and doable. Of course there will always be deployments that are difficult or even impossible to change just partially, but those should not stand in the way of the ones that are doable.

 

Best regards,

Matej

 

 

Matej Artač, Ph.D. / Project Manager
XLAB d.o.o. / Pot za Brdom 100 / SI - 1000 Ljubljana / Slovenia
tel.+386 40 556 755 / info@xlab.si / www.xlab.si

Project Manager, Platform and Systems Orchestration

Member of OASIS TOSCA Standard Technical Committee

Member of steampunk.si

Google Drive / Linkedin / Twitter

 

 

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Chris Lauwers
Sent: Tuesday, August 13, 2019 5:32 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] Agenda for Aug. 13 TOSCA Language Ad-Hoc Meeting

 

  1. Recap of discussions to-date about ‘modifying deployed service instances’
    1. Update vs. upgrade scenarios
    2. How do workflows fit in?
  1. How can TOSCA policies modify deployed service instances, since policies are limited to
    1. Running workflows
    2. Calling interface operations
  1. Prioritize work items focused on using TOSCA as a service modeling language (rather than a service orchestration language)
    1. Based on feedback/input from the team

 

I look forward to another productive discussion on Tuesday.

 

Thanks,

 

Chris

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]