Perhaps. It was copied directly from a working Cloudify blueprint, so I wasn't sure. Discovered it as part of a porting exercise from Cloudify DSL.
On Fri, Oct 6, 2017 at 10:02 AM, Tal Liron <[email protected]> wrote: > I think this is as expected: > > macro: *macro -> macro: { val: { get_attributes: [node1, att1] } } > > *macro -> macro: { get_attributes: [node1, att1] } > > > On Fri, Oct 6, 2017 at 11:50 AM, DeWayne Filppi <[email protected]> > wrote: > > > Actually, there is an oddity here. See the simple template below: > > > > --------------------------------- > > test.yaml > > --------------------------------- > > > > imports: > > - aria-1.0 > > > > node_types: > > > > type_1: > > derived_from: tosca.nodes.Root > > attributes: > > att1: > > type: string > > default: "a val" > > > > dsl_definitions: > > macro: ¯o > > val: { get_attribute: [ node1, att1 ] } > > > > topology_template: > > > > node_templates: > > > > node0: > > type: tosca.nodes.Root > > interfaces: > > Standard: > > create: > > inputs: > > macro: *macro > > implementation: test.sh > > > > requirements: > > - dependency: node1 > > > > node1: > > type: type_1 > > ------------------------------------------- > > test.sh > > ------------------------------------------- > > > > #!/bin/bash > > > > env > /tmp/env > > > > ----------------------------------------------- > > > > When running the install workflow on this, the /tmp/env file shows that > the > > environment variable "macro" contains the string {"val": > {"get_attribute": > > ["node1", "att1"]}}. > > > > This seems odd. On the other hand, if you replace the "macro: *macro" > line > > with just '*macro', then the "val" environment variable contains "a val" > as > > you would expect. > > > > -- DeWayen > > > > > > On Fri, Oct 6, 2017 at 9:22 AM, Tal Liron <[email protected]> wrote: > > > > > Thanks DeWayne, could you explain this in more detail? YAML macros are > > > handled by the underlying YAML parser, not by the TOSCA parser on top > of > > > it, so we would really like to know if there's a bug somewhere. I did > not > > > understand from your explanation what works in Cloudify and not in > ARIA. > > > > > > On Fri, Oct 6, 2017 at 10:25 AM, DeWayne Filppi <[email protected]> > > > wrote: > > > > > > > For those interested, it appears that the "problem" described before > > was > > > > due to the inline macro definition in the "inputs" definition for the > > > > create operation. This odd syntax was the result of a translation > > effort > > > > from a Cloudify DSL blueprint (which apparently tolerates it). If I > > move > > > > the macro definition up into "dsl_definitions", all appears to be > well. > > > > > > > > -- DeWayne > > > > > > > > On Thu, Oct 5, 2017 at 5:01 PM, Tal Liron <[email protected]> wrote: > > > > > > > > > DeWayne, as usual it's very hard for me to follow up on your > > questions. > > > > > > > > > > Please provide more information. At the very least, what is the > full > > > > error > > > > > you see? (I don't understand what "not evaluating" means.) > > > > > > > > > > Also, we need to reproduce this in order the help. Either provide > us > > > > with a > > > > > complete example that we can actually run, or -- much better -- a > > > minimal > > > > > example that can reproduce just this error. > > > > > > > > > > On Thu, Oct 5, 2017 at 6:56 PM, DeWayne Filppi < > [email protected]> > > > > > wrote: > > > > > > > > > > > I'm attempting evaluate 'get_attribute' in an operation input > > clause > > > > like > > > > > > so: > > > > > > > > > > > > fortigate_vnf_baseline_config: > > > > > > type: aria.terminal.raw > > > > > > interfaces: > > > > > > Standard: > > > > > > create: > > > > > > inputs: > > > > > > terminal_auth: &terminal_auth > > > > > > user: admin > > > > > > password: '' > > > > > > ip: { get_attribute: [ fortigate_ip, > > > > floating_ip_address > > > > > ] > > > > > > } > > > > > > > > > > > > When I run the install workflow, the code that evaluates "ip" > sees > > > the > > > > > > string literal "{ get_attribute: [ fortigate_ip, > > floating_ip_address > > > ] > > > > > }". > > > > > > > > > > > > From the spec it seems this should evaluate fine. This seems > > pretty > > > > > > basic, so it seems unlikely to be a bug. Perhaps because it's > in a > > > > YAML > > > > > > macro? > > > > > > > > > > > > -- DeWayne > > > > > > > > > > > > > > > > > > > > >
