RE: [tosca] Re: questions about substitution mapping in the 2.0 draft

By the way, you use the term âimportedâ template. Substituting template are *never* imported. Service templates that contain abstract nodes do not (and should not) have an opinion about which substituting templates should be used to substitute abstract nodes. It is up to the orchestrator to find the best substituting templates.

Thanks,

Chris

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of adam souzis
Sent: Tuesday, December 15, 2020 8:37 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] Re: questions about substitution mapping in the 2.0 draft

Hi all,

Thanks for indulging me on the call today regarding these questions... I thought I understood while we were talking but now I'm not so sure and I can't find any discussion in the 2.0 spec about how the "substitute" directive works. The heart of my question is this, give an abstract node template like this:

aNodeTemplate:

directives:

- substitute

properties:

foo: true

Can you set properties in this sort of template ("foo" in this example)? If you can, does "foo" set the imported template's input based on the map provided by its substitution mapping's properties keyname?

Or is it only visible to the outer template and has no impact on the imported template?

Thanks!

Adam

On Sun, Dec 13, 2020 at 7:22 PM adam souzis <adam@souzis.com> wrote:

In 1.3 a node template with the "substitute" directive could specify properties, capabilities, and requirements. The 2.0 spec says setting properties are not allowed because they might conflict with the property mapping in the substitution template. That makes sense but it is silent on setting requirements and capabilities -- wouldn't they have the same issue?

One thing I don't understand is how to set the inputs on an imported template -- before I thought setting the properties on the substituted node template would do that but now I don't know how they can get set.

Also, I don't understand why section "4.2.6.2.7.1 requirement_mapping" is there -- I assume that's an error? Requirement mappings are already defined in section 4.5.5.

Thanks,

Adam

á

tosca message