I didn't want to confuse this issue before (it was about YAML anchors), but
actually this whole service template should be invalid. This is a known bug
in ARIA in which it allows this, when it actually shouldn't. Which version
of ARIA are you using, by the way?
Once this bug is fixed, ARIA should not be allow to add ad-hoc inputs at a
node template. They are undeclared, un-typed, and thus not coerced behind
the scenes. ARIA has no idea what to do with the "test" input and how to
coerce it. Is it a dict? A list? A primitive type? It has no idea, so it
just sends it as is, of course without any evaluation. (I'll repeat, this
is a bug: the parser should not accept this at all so it would never get to
orchestration).
To do this correctly, declare a data type with that structure ("val" as one
of its properties), then inherit the Standard interface and add an input of
that data type, and finally inherit a new node type that overrides Standard
to use that interface. I believe ARIA would then do the right thing.
On Fri, Oct 6, 2017 at 12:56 PM, DeWayne Filppi <[email protected]> wrote:
> The plot thickens maybe. See below:
>
> ----------------------------------------
> test.yaml
> ----------------------------------------
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> imports:
> - aria-1.0
>
> node_types:
>
> type_1:
> derived_from: tosca.nodes.Root
> attributes:
> att1:
> type: string
> default: "a val"
>
> topology_template:
>
> node_templates:
>
> node0:
> type: tosca.nodes.Root
> interfaces:
> Standard:
> create:
> inputs:
> test:
> val: { get_attribute: [ node1, att1 ] }
> implementation: test.sh
>
> requirements:
> - dependency: node1
>
> node1:
> type: type_1
>
>
> -------------------------------
>
> "test" is delivered as {"val": {"get_attribute": ["node1", "att1"]}} to the
> operation. So basically, "get_attribute" is only evaluated if it's not
> nested.
>
> -- DeWayne
>
>
> 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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
