Re: AriaTosca December Podling Report

[Thomas Nadeau]

Just to give a little more info than the original sharing link message.
The mentors
asked me to share the document with the community that I am using to create
the next podling report.  This way anyone here can provide inputs/edits. I
plan on
submitting this early next Monday, December 11, 2017 at 5PM EST, so please
get your edits/comments into the document or to me by then.

Cheers,

--Tom



On Thu, Dec 7, 2017 at 9:47 AM, Thomas Nadeau (via Google Docs) <
tnadeaua...@gmail.com> wrote:

> tnadeaua...@gmail.com has shared a link to the following document:
> AriaTosca December Podling Report
> 
> Open in Docs
> 
> Google Docs: Create and edit documents online.
> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA
> 
> You have received this email because someone shared a document with you
> from Google Docs. [image: Logo for Google Docs] 
>

RE: ARIA-118 plugin.yaml importing

[D Jayachandran]

Hi Tal,

Finally I was able to rebase and create a new PR for this JIRA. This PR address 
the main improvement of using the "plugin.yaml" in a more efficient way in the 
service templates.

But I could find there is a improvement item in the same JIRA issue outside of 
the plugins usage. Please find the text from JIRA as such.
" The import mechanism could look for imports in the resource-storage 
as well - There could be a directory on the resource-storage designated for 
storing global yaml files for import, thereby simplifying reuse of yaml imports 
across service-templates." 
 
I believe this is addressing the need for a global repository like plugins 
which would just contain the yaml files containing the different TOSCA types. 
We are seeing this repository as "type_definitions" and the yaml files within 
them as "type_definition_files". With a repository as such we can import the 
yaml files in our service-templates as we are handling the plugin import with 
this PR.

My proposal is as below for having a global respository to store YAML files and 
importing them in service templates

Repository structure:
.aria/type_definitions/_/*.yaml

Import definition:
imports:
- file: _
 repository: type_definitions
 
The  and  of a type definition file would be got from the 
metadata section in the service template.

Sample type_definition file

tosca_definitions_version: tosca_simple_yaml_1_0

metadata:
  template_name: test
  template_author: evevenu
  template_version: "1.0"

node_types:
non_normative_type_definition_compute:
derived_from: tosca.nodes.Compute
properties:
name:
  type: string
  required: true
password:
  type: string
  required: true


If you are fine with this, Can we open a new JIRA and contribute it ?
We are already working on this from our side as we have a strong use case for 
it.

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, December 04, 2017 7:22 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: ARIA-118 plugin.yaml importing

Sorry, but I don't think we did a thorough review yet. However, feel free to 
rebase on master and push it again to ensure that the CI tests pass.

On Mon, Dec 4, 2017 at 2:48 PM, Thomas Nadeau  wrote:

> BTW I noticed that the Travis CI failed for your PR earlier. Tal and I 
> discussed and he thinks this might be fixed with a rebase now that 
> ARIA-1 has been pushed.  You can test this theory for yourself by 
> rebasing your branch.
>
> --Tom
>
>
> On Mon, Dec 4, 2017 at 12:31 PM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Thanks Thomas, I made the PR now.
> >
> > -Original Message-
> > From: Thomas Nadeau [mailto:tnad...@apache.org]
> > Sent: Monday, December 04, 2017 1:07 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: ARIA-118 plugin.yaml importing
> >
> > Nothing has changed for non-committers; use the canonical GitHub
> fork->push
> > patches->propose patch request method
> > on the same two GitHub repos:
> >
> > https://github.com/apache/incubator-ariatosca-website
> >
> > and
> >
> > https://github.com/apache/incubator-ariatosca
> >
> > I’ll be on slack from now too if you need additional help.
> >
> > —Tom
> >
> >
> > On Dec 4, 2017, at 8:28 AM, D Jayachandran 
> > 
> > wrote:
> >
> > Hi,
> >
> > I need to contribute for this JIRA item. Previously I had made my 
> > contribution by forking from the apache-ariatosca project.
> > Is the process changed now ? What is the process which I should 
> > follow
> now
> > ?
> >
> >
> > Regards,
> > DJ
> >
>

Re: Website Build + Release

[Arthur Berezin]

John, +1.

Let's update the aria's release process to push  sphynx update on Aria
releases.

The reason the website is currently pulling the release docs and not the
other way around is because we published the docs right after we released
0.1.1 and didn't want to introduce changes in that point in time.

Arthur.

On Wed, Dec 6, 2017, 16:58 Thomas Nadeau  wrote:

>
>
> > On Dec 6, 2017, at 4:40 PM, John D. Ament  wrote:
> >
> > Tom,
> >
> > Based on what I'm seeing, you're getting the current release (0.1.1).
> I'm
> > not seeing anything that pulls the current master into the site.
> >
> > I would recommend that we push from the build to the website, rather than
> > have the website pull this information in.
>
> Ok. Ill take a look shortly.
>
> —Tom
>
>
> >
> > John
> >
> > On Wed, Dec 6, 2017 at 8:59 AM Thomas Nadeau 
> wrote:
> >
> >> We use 2 tools to generate the website: Jekyll (html) and spynx (docs),
> and
> >> both tools generate outputs based on the latest code.
> >>
> >> --Tom
> >>
> >>
> >> On Wed, Dec 6, 2017 at 1:28 PM, John D. Ament 
> >> wrote:
> >>
> >>> All,
> >>>
> >>> I'm troubleshooting from yesterday's identified website issues.  One
> >> thing
> >>> I noticed is that as a part of the website build, we download our
> >> release.
> >>> Why is that?
> >>>
> >>> John
> >>>
> >>
>
>

Re: Lets be verbose on the mailer instead of other wise...

[John D. Ament]

I think it may take a bit of elbow grease to get all of the mailing lists
sorted out.  for instance, the website mentions user@ and dev@.  There's at
least 2 more public mailing lists

commits@, where all of the github emails go out ->
https://lists.apache.org/list.html?comm...@ariatosca.apache.org
issues@, where all of the jira emails go out ->
https://lists.apache.org/list.html?iss...@ariatosca.apache.org

Its fine to have discussions on github, jira since those messages are sent
to lists that are archived.  The main concerns I'm raising around problems
you're facing or development level discussions.  Those shouldn't happen on
slack first, they need to be brought up on list.  There's a few reasons
Apache prefers this:

- Asynchronous communication is preferred, to allow people across multiple
timezones to weigh in.
- There may be missing docs as well, and its a subtle note that we need to
get them documented more (for instance, the recent website issues remind me
that we need to document somewhere that our website is built in Jenkins
using the git-websites label and needs to point to a repo with write
access).

On Wed, Dec 6, 2017 at 10:06 AM Thomas Nadeau  wrote:

> I just wanted to reiterate the advice our mentors have been giving us today
> on Slack about first posting here to the list for any threads of
> discussion/issues/etc... The recommendation is "mailing list first". Please
> try to adhere to this before posting to slack, jira or otherwise as mailing
> list use/chatter is important for our project.
>
> Thanks,
>
> --Tom
>

Lets be verbose on the mailer instead of other wise...

[Thomas Nadeau]

I just wanted to reiterate the advice our mentors have been giving us today
on Slack about first posting here to the list for any threads of
discussion/issues/etc... The recommendation is "mailing list first". Please
try to adhere to this before posting to slack, jira or otherwise as mailing
list use/chatter is important for our project.

Thanks,

--Tom

Re: Loading custom workflows

[Vaishnavi K . R]

Hi Tal,


Good that this has been considered.

As all the three entities are mere python modules, it is good to have a common 
loading mechanism.

But will there be any major change in the existing way of loading plugins and 
using the same in the service template?


Thanks,

/Vaish


From: Tal Liron 
Sent: Wednesday, December 6, 2017 7:27:02 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Loading custom workflows

Great question, and it was asked very recently on this list ...

There is a need for a unified way to dynamically load
extensions/plugins/workflows from CSAR files as well as other places. We
are trying to come with a good, forward-looking architectural design for
this loading mechanism. I will provide an update on this in the next few
days.

On Wed, Dec 6, 2017 at 3:51 PM, Vaishnavi K.R 
wrote:

> Hi,
>
>
> I tried using the custom workflow support provided by ARIA.
>
> In the current ARIA, the custom workflows are directly imported as python
> modules.
>
> It looks like it is loading the python modules that are bundled along with
> the service template in CSAR.
>
>
> Also I could see that you have plans to load it as how the plugins are.
>
> Is anyone working on this?
>
> Will the workflows be packaged as wagon archives and installed?
>
> Will they be referred in the service template with the same convention as
> plugins?
>
>
> Thanks,
>
> /Vaish
>

Re: Website Build + Release

[Thomas Nadeau]

> On Dec 6, 2017, at 4:40 PM, John D. Ament  wrote:
> 
> Tom,
> 
> Based on what I'm seeing, you're getting the current release (0.1.1).  I'm
> not seeing anything that pulls the current master into the site.
> 
> I would recommend that we push from the build to the website, rather than
> have the website pull this information in.

Ok. Ill take a look shortly.

—Tom


> 
> John
> 
> On Wed, Dec 6, 2017 at 8:59 AM Thomas Nadeau  wrote:
> 
>> We use 2 tools to generate the website: Jekyll (html) and spynx (docs), and
>> both tools generate outputs based on the latest code.
>> 
>> --Tom
>> 
>> 
>> On Wed, Dec 6, 2017 at 1:28 PM, John D. Ament 
>> wrote:
>> 
>>> All,
>>> 
>>> I'm troubleshooting from yesterday's identified website issues.  One
>> thing
>>> I noticed is that as a part of the website build, we download our
>> release.
>>> Why is that?
>>> 
>>> John
>>> 
>> 

Re: Website Build + Release

[John D. Ament]

Tom,

Based on what I'm seeing, you're getting the current release (0.1.1).  I'm
not seeing anything that pulls the current master into the site.

I would recommend that we push from the build to the website, rather than
have the website pull this information in.

John

On Wed, Dec 6, 2017 at 8:59 AM Thomas Nadeau  wrote:

> We use 2 tools to generate the website: Jekyll (html) and spynx (docs), and
> both tools generate outputs based on the latest code.
>
> --Tom
>
>
> On Wed, Dec 6, 2017 at 1:28 PM, John D. Ament 
> wrote:
>
> > All,
> >
> > I'm troubleshooting from yesterday's identified website issues.  One
> thing
> > I noticed is that as a part of the website build, we download our
> release.
> > Why is that?
> >
> > John
> >
>

Re: Website Build + Release

[Thomas Nadeau]

We use 2 tools to generate the website: Jekyll (html) and spynx (docs), and
both tools generate outputs based on the latest code.

--Tom


On Wed, Dec 6, 2017 at 1:28 PM, John D. Ament  wrote:

> All,
>
> I'm troubleshooting from yesterday's identified website issues.  One thing
> I noticed is that as a part of the website build, we download our release.
> Why is that?
>
> John
>

Re: Loading custom workflows

[Tal Liron]

Great question, and it was asked very recently on this list ...

There is a need for a unified way to dynamically load
extensions/plugins/workflows from CSAR files as well as other places. We
are trying to come with a good, forward-looking architectural design for
this loading mechanism. I will provide an update on this in the next few
days.

On Wed, Dec 6, 2017 at 3:51 PM, Vaishnavi K.R 
wrote:

> Hi,
>
>
> I tried using the custom workflow support provided by ARIA.
>
> In the current ARIA, the custom workflows are directly imported as python
> modules.
>
> It looks like it is loading the python modules that are bundled along with
> the service template in CSAR.
>
>
> Also I could see that you have plans to load it as how the plugins are.
>
> Is anyone working on this?
>
> Will the workflows be packaged as wagon archives and installed?
>
> Will they be referred in the service template with the same convention as
> plugins?
>
>
> Thanks,
>
> /Vaish
>

Loading custom workflows

[Vaishnavi K . R]

Hi,


I tried using the custom workflow support provided by ARIA.

In the current ARIA, the custom workflows are directly imported as python 
modules.

It looks like it is loading the python modules that are bundled along with the 
service template in CSAR.


Also I could see that you have plans to load it as how the plugins are.

Is anyone working on this?

Will the workflows be packaged as wagon archives and installed?

Will they be referred in the service template with the same convention as 
plugins?


Thanks,

/Vaish

Please review docker image creation wiki

[Thomas Nadeau]

Community:

Vish just published instructions on building Docker images to the wiki.

At your convenience, please review and provide feedback you may have for
content at:

https://cwiki.apache.org/confluence/display/ARIATOSCA/Creating+and+running+a+Docker+Container+for+AriaTosca

Re: install_aria_extensions called twice

[Maxim Orlov]

The removal on the call to install_aria_extensions does solve the problem
in your case, however this might raise other issue. For example: writing a
process executor extension would have no effect if you'd remove the
`install_aria_extensions` function call.

The actual problem is caused because you try to pass a complex data_type,
which get pickled. in the unpicking process the extension gets loaded
automatically, and then it get loaded again via the
`install_aria_extensions`. Indeed this is a bug we need to address (I've
opened a JIRA ticket here ).

On Wed, Dec 6, 2017 at 8:59 AM Srinidhi Srivatsan
 wrote:

> Hi,
>
>
>
> We have observed runtime error “Re-definition of YAML 1.1” error while
> executing the following service template. This happens when we define a
> complex type as input into an operation but the first entry must be an
> intrinsic function even if the type has been defined as string. We think it
> maybe because of the install_aria_extensions being called twice. When
> commenting out the “install_aria_extensions” in process.py(executor),
> execution succeeds.
>
>
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
>
>
> data_types:
>
>   my.datatypes.operation.inputs.Template:
>
> derived_from: tosca.datatypes.Root
>
> properties:
>
>   path:
>
> type: string
>
>   output:
>
> type: my.datatypes.operation.inputs.Template.Output
>
> required: false
>
>
>
>   my.datatypes.operation.inputs.Template.Output:
>
> derived_from: tosca.datatypes.Root
>
> properties:
>
>   runtime_property:
>
> type: string
>
> required: false
>
>   remote_file:
>
> type: my.datatypes.operation.inputs.Template.Output.RemoteFile
>
> required: false
>
>
>
>   my.datatypes.operation.inputs.Template.Output.RemoteFile:
>
> derived_from: tosca.datatypes.Root
>
> properties:
>
>   hostname:
>
> type: string
>
> required: false
>
>   username:
>
> type: string
>
> required: false
>
>   password:
>
> type: string
>
> required: false
>
>   path:
>
> type: string
>
> required: false
>
>
>
> node_types:
>
>   my.nodes.BGW:
>
> derived_from: tosca.nodes.Root
>
> properties:
>
>   host:
>
> type: string
>
> description: bgw host address
>
> interfaces:
>
>   Standard:
>
> type: tosca.interfaces.node.lifecycle.Standard
>
> configure:
>
>   implementation: scripts/test.py
>
>   inputs:
>
> templates:
>
>   type: list
>
>   entry_schema:
>
> type: my.datatypes.operation.inputs.Template
>
> description: "BGW configuration templates"
>
>
>
> topology_template:
>
>
>
> node_templates:
>
>   bgw:
>
> type: my.nodes.BGW
>
> properties:
>
>   host: "{get_input: BGW_HOST }"
>
> interfaces:
>
>   Standard:
>
> configure:
>
>   inputs:
>
> templates:
>
> - path: "configuration-templates/bgw_epg_add"
>
>   output:
>
>   runtime_property: "bgw_epg_add_configuration"
>
>   remote_file:
>
>   hostname: "host" # replace the string with a
> function and you no longer get the error i.e. { get_property: [SELF, host]
> }
>
>   username: "Name"
>
>   password: "Pwd"
>
>   path:  "the path "
>
> - path: "configuration-templates/bgw_mme_add"
>
>
>
> Regards,
>
> Srinidhi.
>
>
>
> *From:* Srinidhi Srivatsan [mailto:srinidhi.srivat...@globallogic.com]
> *Sent:* Wednesday, December 06, 2017 11:41 AM
> *To:* 'dev@ariatosca.incubator.apache.org'
> *Subject:* install_aria_extensions called twice
>
>
>
> Hi,
>
>
>
>We have observed that install_aria_extensions is called twice – once in
> process.py(executor) and once in main.py. Could you please confirm as to
> why it is called again in process.py?
>
>
>
> Regards,
>
> Srinidhi.
>

AriaTosca website published

[Apache Jenkins Server]

The Apache Jenkins build system has built AriaTosca Website (build #42)

Status: Fixed

Check console output at https://builds.apache.org/job/AriaTosca%20Website/42/ 
to view the results.

Website Build + Release

[John D. Ament]

All,

I'm troubleshooting from yesterday's identified website issues.  One thing
I noticed is that as a part of the website build, we download our release.
Why is that?

John

AriaTosca website published

[Apache Jenkins Server]

The Apache Jenkins build system has built AriaTosca Website (build #41)

Status: Failure

Check console output at https://builds.apache.org/job/AriaTosca%20Website/41/ 
to view the results.

AriaTosca website published

[Apache Jenkins Server]

The Apache Jenkins build system has built AriaTosca Website (build #40)

Status: Successful

Check console output at https://builds.apache.org/job/AriaTosca%20Website/40/ 
to view the results.

AriaTosca website published

[Apache Jenkins Server]

The Apache Jenkins build system has built AriaTosca Website (build #39)

Status: Successful

Check console output at https://builds.apache.org/job/AriaTosca%20Website/39/ 
to view the results.

Re: get_attribute function not supporting SELF as

[Tal Liron]

I imagine it is related. :)

On Wed, Dec 6, 2017 at 11:23 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:

> I Just wanted to cross check whether this issue is related to the commit
> "ARIA-349 get_attribute is not calculated at runtime". I will debug into
> this and get back to you for any contribution.
>
> Thank you.
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, December 06, 2017 2:02 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: get_attribute function not supporting SELF as
> 
>
> Thank you for the additional information!
>
> I think that perhaps this bug has to do with setting/retrieving attribute
> data and might not be related to the get_attribute function.
>
> Are you a programmer? Is there any way you can help us debug this on your
> end to find out where things go wrong?
>
> If not, could you possibly share with your complete example, including the
> "sample" plugin code, so that we can debug it?
>
> On Wed, Dec 6, 2017 at 7:07 AM, Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com.invalid> wrote:
>
> > Hi,
> > Yes this scenario is working fine. But in my case, I am not assigning
> > default value to attribute in node type instead assigning the
> > attribute value through a plugin(sample-1.0.0 in my case) using,
> > ctx.node.attributes['config'] = "test" .
> > Then I am trying to fetch this value through get_attribute function in
> > another operation. You can find the service template used below. I
> > saved it as a file named "test.yaml"
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> > imports:
> >   - aria-1.0
> >
> > node_types:
> >   my_Node_Server:
> > derived_from: tosca.nodes.Root
> > attributes:
> >   vmme_configuration:
> > type: string
> >
> > topology_template:
> >policies:
> >  sample:
> >type: aria.Plugin
> >properties:
> >  version: 1.0.0
> >  enabled: true
> >
> >node_templates:
> >  v_mme:
> >type: my_Node_Server
> >interfaces:
> >  Standard:
> >create:
> >  implementation: sample > sample.sample_test.call_test
> >configure:
> >  implementation: sample > sample.sample_test.call_name
> >  inputs:
> >config: {get_attribute: [ v_mme, vmme_configuration ]}
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Tuesday, December 05, 2017 7:05 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: get_attribute function not supporting SELF as
> > 
> >
> > Sure, it is seen below. I saved it as a file named "v.yaml" and then
> > ran these commands to see the values of the function calls, which in
> > both cases was "hello":
> >
> > aria service-templates store v.yaml v
> > aria service-templates show v -f
> >
> > The file "v.yaml":
> >
> > tosca_definitions_version: tosca_simple_yaml_1_0
> >
> > data_types:
> >
> >   Payload:
> > properties:
> >   config:
> > type: string
> >
> > node_types:
> >
> >   my_Node_Server:
> > derived_from: tosca.nodes.Root
> > attributes:
> >   vmme_configuration:
> > type: string
> > default: hello
> > interfaces:
> >   Standard:
> > type: tosca.interfaces.node.lifecycle.Standard
> > create:
> >   implementation: sample.sample_test.call_test
> >   inputs: {}
> > configure:
> >   implementation: sample.sample_test.call_name
> >   inputs:
> > payload:
> >   type: Payload
> >
> > topology_template:
> >
> >node_templates:
> >  v_mme:
> >type: my_Node_Server
> >interfaces:
> >  Standard:
> >configure:
> >  inputs:
> >payload: {
> >  "config": {get_attribute: [ SELF, vmme_configuration ]}}
> >config: {get_attribute: [ SELF, vmme_configuration ]}
> >
> >
> >
> >
> > On Tue, Dec 5, 2017 at 1:56 PM, Vaishali Krishnamurthy <
> > v.krishnamurt...@globallogic.com.invalid> wrote:
> >
> > > I have tried the same in the latest master version. Could you please
> > > provide the service template you used ?
> > >
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@cloudify.co]
> > > Sent: Tuesday, December 05, 2017 3:41 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: get_attribute function not supporting SELF as
> > > 
> > >
> > > I tried here and it did work for me. Are you using the latest master
> > > version? We had a few recent commits that have fixed various things.
> > >
> > > Perhaps you can provide a fully working minimal example that could
> > > clearly reproduce this bug?
> > >
> > > On Tue, Dec 5, 2017 at 12:02 PM, Vaishali Krishnamurthy <
> > > v.krishnamurt...@globallogic.com.invalid> wrote:
> > >
> > > > Thanks. I tried this workaround. Still, the get_attribute function
> > > > 

RE: get_attribute function not supporting SELF as

[Vaishali Krishnamurthy]

I Just wanted to cross check whether this issue is related to the commit
"ARIA-349 get_attribute is not calculated at runtime". I will debug into
this and get back to you for any contribution.

Thank you.

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co]
Sent: Wednesday, December 06, 2017 2:02 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: get_attribute function not supporting SELF as


Thank you for the additional information!

I think that perhaps this bug has to do with setting/retrieving attribute
data and might not be related to the get_attribute function.

Are you a programmer? Is there any way you can help us debug this on your
end to find out where things go wrong?

If not, could you possibly share with your complete example, including the
"sample" plugin code, so that we can debug it?

On Wed, Dec 6, 2017 at 7:07 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:

> Hi,
> Yes this scenario is working fine. But in my case, I am not assigning
> default value to attribute in node type instead assigning the
> attribute value through a plugin(sample-1.0.0 in my case) using,
> ctx.node.attributes['config'] = "test" .
> Then I am trying to fetch this value through get_attribute function in
> another operation. You can find the service template used below. I
> saved it as a file named "test.yaml"
>
> tosca_definitions_version: tosca_simple_yaml_1_0
> imports:
>   - aria-1.0
>
> node_types:
>   my_Node_Server:
> derived_from: tosca.nodes.Root
> attributes:
>   vmme_configuration:
> type: string
>
> topology_template:
>policies:
>  sample:
>type: aria.Plugin
>properties:
>  version: 1.0.0
>  enabled: true
>
>node_templates:
>  v_mme:
>type: my_Node_Server
>interfaces:
>  Standard:
>create:
>  implementation: sample > sample.sample_test.call_test
>configure:
>  implementation: sample > sample.sample_test.call_name
>  inputs:
>config: {get_attribute: [ v_mme, vmme_configuration ]}
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, December 05, 2017 7:05 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: get_attribute function not supporting SELF as
> 
>
> Sure, it is seen below. I saved it as a file named "v.yaml" and then
> ran these commands to see the values of the function calls, which in
> both cases was "hello":
>
> aria service-templates store v.yaml v
> aria service-templates show v -f
>
> The file "v.yaml":
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> data_types:
>
>   Payload:
> properties:
>   config:
> type: string
>
> node_types:
>
>   my_Node_Server:
> derived_from: tosca.nodes.Root
> attributes:
>   vmme_configuration:
> type: string
> default: hello
> interfaces:
>   Standard:
> type: tosca.interfaces.node.lifecycle.Standard
> create:
>   implementation: sample.sample_test.call_test
>   inputs: {}
> configure:
>   implementation: sample.sample_test.call_name
>   inputs:
> payload:
>   type: Payload
>
> topology_template:
>
>node_templates:
>  v_mme:
>type: my_Node_Server
>interfaces:
>  Standard:
>configure:
>  inputs:
>payload: {
>  "config": {get_attribute: [ SELF, vmme_configuration ]}}
>config: {get_attribute: [ SELF, vmme_configuration ]}
>
>
>
>
> On Tue, Dec 5, 2017 at 1:56 PM, Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com.invalid> wrote:
>
> > I have tried the same in the latest master version. Could you please
> > provide the service template you used ?
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Tuesday, December 05, 2017 3:41 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: get_attribute function not supporting SELF as
> > 
> >
> > I tried here and it did work for me. Are you using the latest master
> > version? We had a few recent commits that have fixed various things.
> >
> > Perhaps you can provide a fully working minimal example that could
> > clearly reproduce this bug?
> >
> > On Tue, Dec 5, 2017 at 12:02 PM, Vaishali Krishnamurthy <
> > v.krishnamurt...@globallogic.com.invalid> wrote:
> >
> > > Thanks. I tried this workaround. Still, the get_attribute function
> > > returns the value 'none' when used in the first level of inputs.
> > > In my case, I am trying to update the attribute value in one
> > > operation using plugin and fetch the updated attribute value in
> > > another operation using the get_attribute function, for which it
> > > returns 'none' when I use SELF as modelable entity.
> > > For the same scenario if I use the node name as modelable entity,
> > > it works fine.
> > >
> 

Re: get_attribute function not supporting SELF as

[Tal Liron]

Thank you for the additional information!

I think that perhaps this bug has to do with setting/retrieving attribute
data and might not be related to the get_attribute function.

Are you a programmer? Is there any way you can help us debug this on your
end to find out where things go wrong?

If not, could you possibly share with your complete example, including the
"sample" plugin code, so that we can debug it?

On Wed, Dec 6, 2017 at 7:07 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:

> Hi,
> Yes this scenario is working fine. But in my case, I am not assigning
> default value to attribute in node type instead assigning the attribute
> value through a plugin(sample-1.0.0 in my case) using,
> ctx.node.attributes['config'] = "test" .
> Then I am trying to fetch this value through get_attribute function in
> another operation. You can find the service template used below. I saved it
> as a file named "test.yaml"
>
> tosca_definitions_version: tosca_simple_yaml_1_0
> imports:
>   - aria-1.0
>
> node_types:
>   my_Node_Server:
> derived_from: tosca.nodes.Root
> attributes:
>   vmme_configuration:
> type: string
>
> topology_template:
>policies:
>  sample:
>type: aria.Plugin
>properties:
>  version: 1.0.0
>  enabled: true
>
>node_templates:
>  v_mme:
>type: my_Node_Server
>interfaces:
>  Standard:
>create:
>  implementation: sample > sample.sample_test.call_test
>configure:
>  implementation: sample > sample.sample_test.call_name
>  inputs:
>config: {get_attribute: [ v_mme, vmme_configuration ]}
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, December 05, 2017 7:05 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: get_attribute function not supporting SELF as
> 
>
> Sure, it is seen below. I saved it as a file named "v.yaml" and then ran
> these commands to see the values of the function calls, which in both cases
> was "hello":
>
> aria service-templates store v.yaml v
> aria service-templates show v -f
>
> The file "v.yaml":
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> data_types:
>
>   Payload:
> properties:
>   config:
> type: string
>
> node_types:
>
>   my_Node_Server:
> derived_from: tosca.nodes.Root
> attributes:
>   vmme_configuration:
> type: string
> default: hello
> interfaces:
>   Standard:
> type: tosca.interfaces.node.lifecycle.Standard
> create:
>   implementation: sample.sample_test.call_test
>   inputs: {}
> configure:
>   implementation: sample.sample_test.call_name
>   inputs:
> payload:
>   type: Payload
>
> topology_template:
>
>node_templates:
>  v_mme:
>type: my_Node_Server
>interfaces:
>  Standard:
>configure:
>  inputs:
>payload: {
>  "config": {get_attribute: [ SELF, vmme_configuration ]}}
>config: {get_attribute: [ SELF, vmme_configuration ]}
>
>
>
>
> On Tue, Dec 5, 2017 at 1:56 PM, Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com.invalid> wrote:
>
> > I have tried the same in the latest master version. Could you please
> > provide the service template you used ?
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Tuesday, December 05, 2017 3:41 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: get_attribute function not supporting SELF as
> > 
> >
> > I tried here and it did work for me. Are you using the latest master
> > version? We had a few recent commits that have fixed various things.
> >
> > Perhaps you can provide a fully working minimal example that could
> > clearly reproduce this bug?
> >
> > On Tue, Dec 5, 2017 at 12:02 PM, Vaishali Krishnamurthy <
> > v.krishnamurt...@globallogic.com.invalid> wrote:
> >
> > > Thanks. I tried this workaround. Still, the get_attribute function
> > > returns the value 'none' when used in the first level of inputs. In
> > > my case, I am trying to update the attribute value in one operation
> > > using plugin and fetch the updated attribute value in another
> > > operation using the get_attribute function, for which it returns
> > > 'none' when I use SELF as modelable entity.
> > > For the same scenario if I use the node name as modelable entity, it
> > > works fine.
> > >
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@cloudify.co]
> > > Sent: Tuesday, December 05, 2017 3:10 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: get_attribute function not supporting SELF as
> > > 
> > >
> > > The bug, in case you want to follow its progress:
> > > https://issues.apache.org/jira/browse/ARIA-424
> > >
> > > On Tue, Dec 5, 2017 at 11:35 AM, Tal Liron