Re: [tosca] New syntax for function calls

[Tal Liron <tliron@redhat.com>]

As a side note -- we've tabled the proposal that TOSCA could be made more extensible than it already is by formally acknowledging that some implementations would add additional "custom" functions.

It's a delicate issue. As Chris pointed out, it would limit portability if users indeed use such functions. On the other hand, ... there's nothing we can do to stop implementations from adding functions, and indeed it seems like a natural and "correct" way to add various features.

TOSCA already supports metadata everywhere, which allows implementations to ... add any custom data. So, why not acknowledge in the specification that there may be additional functions in some implementations? We can at least provide guidelines for when new functions should be introduced and encourage more portable solutions.

But we can also go a step further, and perhaps allow these custom functions to be "forward-declared", at least by name, so that other TOSCA processors would at least not consider these functions calls as errors. E.g.:

tosca_definitions_version: tosca_2_0

functions:

- q

- get_output

topology_template:

...

On Wed, Mar 17, 2021 at 9:07 AM adam souzis <adam@souzis.com> wrote:

Sure, it's just a tosca function that returns its value, so to use your first example:

mynode:

 type: MyType

 properties:

  name: {Âq: { get_input: site } }

Though of course it much nicer written out like this:

mynode:

 type: MyType

 properties:

  name:Â

   q: { get_input: site }

á

On Wed, Mar 17, 2021 at 7:02 AM Tal Liron <tliron@redhat.com> wrote:

Right, that proposal was weird for exactly that reason -- treating a name (a non-value) as a value. That's part of the reason I added a second version of that proposal, of using the "aliases" keyword in which actual values are expected. Can you show us an example from Unfurl of using "q"?

On Wed, Mar 17, 2021 at 7:06 AM adam souzis <adam@souzis.com> wrote:

Good point, there isn't any ambiguity if there's a leading escape character. I was thing more about your example for node templates, e.g.Â

"{ concat: [ site-, { get_variable: [ SITE, name ] } ] }"

How do you know it'sÂnot a template with that name?

BTW, for the issue you brought up about functions, in Unfurl I have a function called "q" (for "quote") that resolves to its value. That solves the problem in a similarÂway but doesn't introduce any new syntax.