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