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 <t...@cloudify.co> 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 <dewa...@cloudify.co> > 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 <t...@cloudify.co> 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 <dewa...@cloudify.co> > > > 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 > > > > > > > > > >