Re: [tosca] Agenda for Tuesday Apr. 6, 2021 TOSCA Language Ad-Hoc meeting

[adam souzis <adam@souzis.com>]

sure, here's an example from TOSCA Simple Profile in YAML Version 1.3 (actually i'm combining two examples for completeness):

substitution_mappings:
 node_type: example.TransactionSubsystemÂ

 properties:

      rules: [ rulesInput ]

 capabilities:

  message_receiver: [ app, message_receiver ]

 requirements:

 Âdatabase_endpoint: [ app, database ]Â

node_templates:

 root:

  directives:

   Â- substitution_mapping

  Ânode_type: example.TransactionSubsystemÂ

  properties:

   Ârules: {get_input: rulesInput }

 ÂÂcapabilities:

  message_receiver:

   property1: {get_property: [app, message_receiver,ÂÂproperty1]

ÂÂrequirements: Â Â

   database_endpoint:Â

    Ânode: database Â# direct reference to app database requirement target node

 Â# topology outputs could be mapped to attributes

 Âattributes:

  Âoutput1: {get_attribute: [app, attribute1]}

Â

The main expressiveness I see missing compared to the subsitution_mapping is that I have to directly specify the requirement target node; this could be solved by introducing a "get_requirement" TOSCA function so we could write this:

{get_requirement: [app, database]}

Adam

On Tue, Apr 6, 2021 at 8:37 AM Tal Liron <tliron@redhat.com> wrote:

Adam, could you possibly write out an example of using a node template instead of using substitution mapping? It will help me understand what exactly you have in mind (I think I do, but not sure).

On Tue, Apr 6, 2021 at 10:14 AM adam souzis <adam@souzis.com> wrote:

Thanks for discussing this on the call today... I feel like I am missing something -- assuming that this "root" node template is "virtual" in the same withÂthe same semantics as a substitution_mapping -- is there anything that the "substitution_mapping" syntax can express that a node_template can'tÂ

syntactically? Not saying this is a good idea or not -- I'm just trying to make sure I understand this...

On Tue, Apr 6, 2021 at 5:50 AM adam souzis <adam@souzis.com> wrote:

In preparations for this meeting I struggled to understand the semantic of substitution mappings and come to the conclusion that they aren't needed!

* If a substituted node template is chosenÂby the orchestrator from its inventory than I don't see why we need a separate "substitute" directive -- "select" shouldÂbe sufficient. Why should the template care about what mechanism the orchestrator uses to pick a nodeÂin its inventory? Regarding the node template's properties: they just have to be present as specified, if that implies that the orchestrator will fulfillÂthat that by passing them through as inputs to another template that seems irrelevant to the outer node template.Â

* All the functionality of "substitution_mappings" is available by simply adding a node template directive like "export" or "root" which indicates that that node_template should be used to "represent" the topology. That node template is already as expressive as a substitution_mapping:

- input mappings are available through get_input

- capabilities mappings can be specified using get_property

- requirements mappings just need to declare the target node directly.

I think simplifyingÂthe spec like this would be a big win.

BTW version 1.3 describes "substitutions_mappings" as a list its grammar -- I assume that's an error but that could be supported in this proposal simply by allowing multiple node templates to use this "export" directive.

Cheers,

Adam

On Mon, Apr 5, 2021 at 9:41 PM Chris Lauwers <lauwers@ubicity.com> wrote:

• We will discuss substitution mapping
• Specifically as it relates to exchanging information between the substituted node and the substituting template

Â

Thanks,

Â

Chris