Re: Working towards Release 1

[Suneel Marthi]

Everything's gonna happen on list @John - spoke with Tal and Thomas
already.

On Fri, Oct 6, 2017 at 7:34 PM, John D. Ament  wrote:

> What's weekly grooming? Does it happen on list? If I don't work at
> Cloudify, how do I participate in weekly grooming?
>
> John
>
> On Thu, Oct 5, 2017 at 12:09 PM Thomas Nadeau 
> wrote:
>
> >
> > Agreed. We can update the Jira on the weekly grooming.
> >
> > —Tom
> >
> >
> > > On Oct 5, 2017, at 11:24 AM, Tal Liron  wrote:
> > >
> > > I think we can discuss the epic in general here, and leave
> implementation
> > > details on JIRA.
> > >
> > > On Thu, Oct 5, 2017 at 9:52 AM, Vishwanath Jayaraman <
> > > vishwana...@hotmail.com> wrote:
> > >
> > >> Tal/Tom,
> > >>
> > >> Very glad to see an epic and its associated stories/tasks for Release
> > 1.0.
> > >>
> > >> I am assuming you are expecting the comments(if any) in the JIRA
> itself,
> > >> right?
> > >>
> > >> Vish
> > >>
> > >>
> > >> 
> > >> From: Thomas Nadeau 
> > >> Sent: Wednesday, October 4, 2017 3:38 PM
> > >> To: dev@ariatosca.incubator.apache.org
> > >> Subject: Working towards Release 1
> > >>
> > >>
> > >>Tal and I sat down yesterday and started with a new epic (
> > >> https://issues.apache.org/jira/browse/ARIA-386)
> > >> in order to begin to capture what we think as a project, is needed to
> > get
> > >> Aria to a stable release 1.0.  I like to do
> > >> releases in “themes” so for this one it is simple: TOSCA 1.0
> > “compliance”
> > >> as we see it.  There are related issues to
> > >> releasing things, but this is a start. Please take a look and comment
> > here.
> > >>
> > >>—Tom
> > >>
> > >>
> >
> >
>

Re: Working towards Release 1

[John D. Ament]

What's weekly grooming? Does it happen on list? If I don't work at
Cloudify, how do I participate in weekly grooming?

John

On Thu, Oct 5, 2017 at 12:09 PM Thomas Nadeau 
wrote:

>
> Agreed. We can update the Jira on the weekly grooming.
>
> —Tom
>
>
> > On Oct 5, 2017, at 11:24 AM, Tal Liron  wrote:
> >
> > I think we can discuss the epic in general here, and leave implementation
> > details on JIRA.
> >
> > On Thu, Oct 5, 2017 at 9:52 AM, Vishwanath Jayaraman <
> > vishwana...@hotmail.com> wrote:
> >
> >> Tal/Tom,
> >>
> >> Very glad to see an epic and its associated stories/tasks for Release
> 1.0.
> >>
> >> I am assuming you are expecting the comments(if any) in the JIRA itself,
> >> right?
> >>
> >> Vish
> >>
> >>
> >> 
> >> From: Thomas Nadeau 
> >> Sent: Wednesday, October 4, 2017 3:38 PM
> >> To: dev@ariatosca.incubator.apache.org
> >> Subject: Working towards Release 1
> >>
> >>
> >>Tal and I sat down yesterday and started with a new epic (
> >> https://issues.apache.org/jira/browse/ARIA-386)
> >> in order to begin to capture what we think as a project, is needed to
> get
> >> Aria to a stable release 1.0.  I like to do
> >> releases in “themes” so for this one it is simple: TOSCA 1.0
> “compliance”
> >> as we see it.  There are related issues to
> >> releasing things, but this is a start. Please take a look and comment
> here.
> >>
> >>—Tom
> >>
> >>
>
>

Re: Slack

[Vishwanath Jayaraman]

Please add vishwana...@hotmail.com

Sent from my iPhone

On Oct 6, 2017, at 5:35 PM, Suneel Marthi 
> wrote:

...and i can add interested folks to the slack channel - just need your
preferred email.

On Fri, Oct 6, 2017 at 3:51 PM, Tal Liron 
> wrote:

Hi, devs!

As you have probably surmised from reading the digests sent to this list,
there is a Slack channel where ARIA devs can chat. I thought it was for
committers only, but in fact any contributor can join and talk to others in
a more real-time fashion.

It's critical to understand that Slack is *not* a replacement for email.
Slack is *not* a place for support questions: all those should to the dev
mailing list, like they do now. Slack is for *coordination* of development
activities that are already in progress.

ASF is email-centric by design. This ensures an even playing field for
contributors from all time zones and with all variations of Internet
accessibility. We should never use Slack to exclude anyone.

With that in mind, if you think it would be useful for you, please respond
to this email with a request to be invited to Slack. We will use the same
email you use here to invite you.

list of maps

[DeWayne Filppi]

How would one define a property that was a list of maps, e.g.

prop:
  -  a: b
  -  c: d


-- DeWayne

Re: Slack

[Suneel Marthi]

...and i can add interested folks to the slack channel - just need your
preferred email.

On Fri, Oct 6, 2017 at 3:51 PM, Tal Liron  wrote:

> Hi, devs!
>
> As you have probably surmised from reading the digests sent to this list,
> there is a Slack channel where ARIA devs can chat. I thought it was for
> committers only, but in fact any contributor can join and talk to others in
> a more real-time fashion.
>
> It's critical to understand that Slack is *not* a replacement for email.
> Slack is *not* a place for support questions: all those should to the dev
> mailing list, like they do now. Slack is for *coordination* of development
> activities that are already in progress.
>
> ASF is email-centric by design. This ensures an even playing field for
> contributors from all time zones and with all variations of Internet
> accessibility. We should never use Slack to exclude anyone.
>
> With that in mind, if you think it would be useful for you, please respond
> to this email with a request to be invited to Slack. We will use the same
> email you use here to invite you.
>

RE: Unique identification of an instance element across services

[Steve Baillargeon]

Hi
About the UUID. 
As far as I know and mentioned a number of times, ARIA already support 
different kinds of ID generation. 
I have nothing to add on this topic.

I would like to focus on the service-template name and the 'already exist' 
error generated by ARIA when the user submits a service-template with a name 
that is "already-in-use".
When will this problem be resolved? Do we have a Jira for it?
As previously indicated, ARIA must allow for duplicate service-template names.

Here are the best practices for API regarding individual resource names and 
resource IDs.

1) The resource name is generated by the API consumer. It is optional. The 
resource name does *not* need to be globally unique. The resource name is 
usually human-readable.
2) If resource name is not generated by the API consumer, the API producer does 
not need to (automatically) generate a resource name. 
3) The resource identifier is generated by the API producer. The resource 
identifier must be "globally unique". The resource ID does not need to be 
human-readable.
4) The API producer must use the resource identifier to uniquely identify the 
resource. It shall not use the resource name for identification purpose. The 
resource name (if provided) is metadata associated with the resource.
5) The API consumer must provide the resource ID when performing an operation 
on an existing resource.

Regarding CLI and the existing Jira.
https://issues.apache.org/jira/browse/ARIA-221
I don't think it is a good idea.
In fact, I think the API guidelines should apply to CLI as well.
The main difference will be on the choice of the resource identifier algorithm.
If CLI user wants a "human-readable" ID, then selects one that is appropriate 
for it.
If API user wants a true UUID, the selects a version 1 UUID for instance.
I suspect the choice of the resource identifier algorithm can be system-wide or 
per interface (?)

-Steve B



-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, October 02, 2017 11:52 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Unique identification of an instance element across services

I suggest that this discussion isn't too important now.

What's important is that we have support for user configuration in ARIA, and 
that it is possible to easily switch between different kinds of ID generation.

Once we have that working, we can go back to discussing what the default should 
be. As users gain some experience playing with different IDs we could get 
feedback.

On Thu, Sep 28, 2017 at 9:29 AM, Vaishnavi K.R 
wrote:

> Thanks Tal.
>
>
> I think many of us are not convinced with the inclusion of the UUID 
> for element identification.
>
> As of now, we have ID for the unique identification. So why should we 
> restrict the users from giving duplicate names for the service templates.
>
>
> I wish to confirm if anyone has a second opinion in allowing duplicate 
> names.
>
> If not, I can raise a JIRA issue and fix it.
>
> Looking forward to your comments.
>
>
> Thanks,
>
> /Vaish
>
> 
> From: Tal Liron 
> Sent: Tuesday, September 26, 2017 2:04:50 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Unique identification of an instance element across 
> services
>
> DeWayne, I think you missed parts of this discussion where we answered 
> some these issues:
>
> 1) ARIA *does* allow you configure you choice of ID generation, and I 
> agree it can be an integration requirement. (We have a JIRA open to 
> give this configuration a CLI.)
> 2) ARIA has a choice of UUID formats beyond the very long 36-character hex.
> Base57 is 22 characters and designed for human readability.
> 3) All the costs you mention seem very negligible to me. ARIA's 
> database storage is tiny. UUID generation happens only when new nodes 
> are created, and is many orders of magnitude faster than storing anything in 
> a database.
>
> It doesn't easy to resolve this issue, as there are two camps here. 
> But I'm very convinced that Vaish and I are correct here. :) Node (and 
> service) names in the real world are used for other systems beyond 
> ARIA once the nodes are installed: names become domain names linked to 
> IP addresses, names of operating system services, registration IDs for 
> message queues, analytics IDs, etc. For all of these a collision is 
> disastrous, and Vaish is right that if it's set up initially by ARIA 
> there is no need to do anything else.
>
> The only possible user discomfort is in using the "aria nodes show", 
> which frankly is a command that I have never even used myself. As for 
> logs, in any install that has more than one service you will be 
> filtering by workflow ID or service ID anyway.
>
> Also, in case there was any confusion: we are talking about node names 
> here, not database IDs. The database IDs are entirely handled within 
> the database and are obviously unique only per table and per 
> 

Slack

[Tal Liron]

Hi, devs!

As you have probably surmised from reading the digests sent to this list,
there is a Slack channel where ARIA devs can chat. I thought it was for
committers only, but in fact any contributor can join and talk to others in
a more real-time fashion.

It's critical to understand that Slack is *not* a replacement for email.
Slack is *not* a place for support questions: all those should to the dev
mailing list, like they do now. Slack is for *coordination* of development
activities that are already in progress.

ASF is email-centric by design. This ensures an even playing field for
contributors from all time zones and with all variations of Internet
accessibility. We should never use Slack to exclude anyone.

With that in mind, if you think it would be useful for you, please respond
to this email with a request to be invited to Slack. We will use the same
email you use here to invite you.

Re: get_attribute not evaluating

[DeWayne Filppi]

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 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 
> 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  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 
> > > 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: 
> > > > 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  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 <
> dewa...@cloudify.co
> > >
> > > > > wrote:
> > 

Re: get_attribute not evaluating

[Tal Liron]

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

Re: get_attribute not evaluating

[DeWayne Filppi]

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  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 
> 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: 
> > 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  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 
> > > 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  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 <
> dewa...@cloudify.co>
> > > > > 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: _auth
> > > > > > user: admin
> > > > > > password: ''
> > > > > > ip: { get_attribute: [ fortigate_ip,
> > > > floating_ip_address
> > > > > ]
> > > > > > }
> > > > > >
> > > > > > When I run the install workflow, the code that evaluates "ip"
> sees
> > > 

Re: get_attribute not evaluating

[DeWayne Filppi]

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, 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:
> >
> > -
> > 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: 
> > 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  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 
> > > 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  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 <
> dewa...@cloudify.co>
> > > > > 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: _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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: get_attribute not evaluating

[Tal Liron]

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

Re: get_attribute not evaluating

[DeWayne Filppi]

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

Re: get_attribute not evaluating

[Tal Liron]

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

Re: get_attribute not evaluating

[DeWayne Filppi]

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