RE: Agenda for Tuesday June 22, 2021 TOSCA Language Ad-Hoc Meeting

[Chris Lauwers <lauwers@ubicity.com>]

(My apologies, just catching up on old emails).

 

Hi Peter, you’re correct that the “minimum+desired” semantics don’t make sense if UNBOUNDED is allowed as an upper bound.

 

My preference is to use a simple integer value rather than a range for “occurrences” in relationship assignments. To avoid confusion with the “occurrences” in requirement definitions, we should likely pick a different keyword (something other than “occurrences”) in relationship assignments.

 

Thanks,

 

Chris

 

From: Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com>
Sent: Monday, June 21, 2021 11:46 PM
To: Chris Lauwers <lauwers@ubicity.com>; tosca@lists.oasis-open.org
Subject: RE: Agenda for Tuesday June 22, 2021 TOSCA Language Ad-Hoc Meeting

 

Agree that we cannot have relationships where the type is unknown.

 

Concerning occurrences, it is clear that if we want to be able to say:

 

   occurrences: [0, UNBOUNDED]

 

then UNBOUNDED  as the upper bound as meaning the desired number makes no sense.

 

But today a range is supported, and the three options in the PPT indicate that if the upper bound is not the desired one, then support for a range should be completely discontinued.

 

So none of the three options are backwards compatible with TOSCA 1.3 – is that intended? I have no strong feelings about that, but others may have.

 

So if range should be supported, but the minimum+desired semantics are not meaningful, what other options for the meaning of the range could be considered? TOSCA 1.3 just say that these numbers are the minimum and maximum, but not how the actual number should be chosen. It could be defined by:

 

• An integer type input (or property?) that has to have a value between the minimum and the maximum. Values outside the range must cause an orchestration error.
• A policy specification (not necessarily the current Policy type in TOSCA):
• Eager: The minimum/desired interpretation
• Balanced: The orchestrator automatically distributes nodes with the required capabilities among nodes that require them
• Custom: Some hook into a more advanced (artifact/script?) algorithm. Example: Geography-aware binding of nodes to requirements.
• Down to a Profile to decide – really the same as policy, except it is pushing the decision out of the language and into a profile implementation, making it harder in case there might be the need to support multiple policies within the same template.

 

Also, considering our end-to-end management charter, the policy may not only be evaluated at initial deployment, but should also work in day 2 scenarios, potentially triggered by closed loop monitoring.

 

Peter

 

 

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Chris Lauwers
Sent: 22. juni 2021 06:30
To: tosca@lists.oasis-open.org
Subject: [tosca] Agenda for Tuesday June 22, 2021 TOSCA Language Ad-Hoc Meeting

 

Our substitution mapping discussions (and specifically the requirement mapping portion) have made it clear that we may not yet be completely aligned on requirements. We will revisit requirements  definitions and requirement assignments to get to a common understanding. I plan to use the attached to help guide the discussion.

 

Thanks,

 

Chris