Next in thread → Next in month →

RE: [tosca] Substitution Inputs

From
Chris Lauwers <>
Date
2021-05-23T19:37:49+00:00
ID
Thread
RE: [tosca] Substitution Inputs
Apologies for the delayed reply. 

 

It appears there still is a lot of confusion about the âsubstitution mappingâ feature. When I said that âit is the responsibility of the substituting templateâ, that means âit is the responsibility of the designer of the substituting templateâ.
 Substituting templates must be created AT DESIGN TIME to be valid substitutions. All the definitions related to substitution can be fully validated at design time, just as with anything else at runtime. There is no validation that cannot be performed until
 runtime.

 

Thanks,

 

Chris

 

From: Tal Liron <> 

Sent: Sunday, April 18, 2021 12:44 PM

To: Chris Lauwers <>

Cc: 

Subject: Re: [tosca] Substitution Inputs

 

On Sun, Apr 18, 2021 at 2:28 PM Chris Lauwers <> wrote:

If âsharingâ is your goal, then you should use requirement fulfillment (likely using selectable nodes), not substitution mapping. The objective of these
 two (very different) features is not the same.

 

The goal is service composition, which indeed involves abstraction. But substitution mapping, as it is right now, is extremely limited in functionality (and also confusing). We rely on "mapping" as the exposing mechanic, but it's limited
 and it overlaps with our explicit methods of mapping values -- functions like get_property and get_attribute. You can prefer say that we are not "injecting" values, but that's what ends up happening. You are just insisting that we only "expose" things through
 an existing node template (mapping properties and attributes to inputs and outputs). It's limited and also very non-deterministic. As you point out, "It is the responsibility of the substituting template to make sure all its required input values can be obtained
 from a property value in the substituted node somehow." This is quite a bit of responsibility! You would end up only finding out that you did something wrong in runtime, when composition actually happens. This seems to go against what we hope to achieve in
 TOSCA, that all designs can be validated during design-time.
Next in thread → Next in month →