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
> > > > >
> > > >
> > >
> >
>
