0.2.0. Makes sense. I thought it odd that inputs could be arbitrary.
On Fri, Oct 6, 2017 at 11:08 AM, Tal Liron <[email protected]> wrote:
> 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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
