OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

 View Only

RE: [tosca] Substitution Inputs

  • 1.  RE: [tosca] Substitution Inputs

    Posted 05-23-2021 19:38




    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.