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

 View Only

RE: [tosca] New syntax for function calls

  • 1.  RE: [tosca] New syntax for function calls

    Posted 03-19-2021 18:54




    A couple of comments:
     

    I think I would prefer the use of a reserved character to indicate that a name refers to a function. It keeps things more compact. If we re planning on including a functions block, then it would be desirable to not just declare the functions, but also provide an implementation (e.g. through artifacts).
    I remember seeing a proposal from Calin in this area.
     
    I ll put this on the list of topics to discuss during one of our Language Ad-Hoc meetings.
     
    Thanks,
     
    Chris
     

    From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org>
    On Behalf Of Tal Liron
    Sent: Wednesday, March 17, 2021 8:14 AM
    To: adam souzis <adam@souzis.com>
    Cc: tosca@lists.oasis-open.org
    Subject: Re: [tosca] New syntax for function calls

     


    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.