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