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 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 whic
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
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:
ty
Perhaps. It was copied directly from a working Cloudify blueprint, so I
wasn't sure. Discovered it as part of a porting exercise from Cloudify DSL.
On Fri, Oct 6, 2017 at 10:02 AM, Tal Liron wrote:
> I think this is as expected:
>
> macro: *macro->macro: { val: { get_attributes: [node1
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 wrote:
> Actually, there is an oddity here. See the simple template below:
>
> --
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 va
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,
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 macr
"Not evaluates" means I put a log statement in the python that uses "ip",
and the value is the "get_attribute" string. I'll try to create a super
simple example.
On Thu, Oct 5, 2017 at 5:01 PM, Tal Liron wrote:
> DeWayne, as usual it's very hard for me to follow up on your questions.
>
> Please
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 exampl
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
11 matches
Mail list logo
