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] 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 <tliron@redhat.com>
Sent: Sunday, April 18, 2021 12:44 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Substitution Inputs

 

On Sun, Apr 18, 2021 at 2:28 PM Chris Lauwers <lauwers@ubicity.com> 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.

 

 



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