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