RE: install_aria_extensions called twice
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.
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.
RE: get_attribute function not supporting SELF as
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 wrote:
> >
> > > There is a bug here, but it has nothing to do with SELF.
> > >
> > > The issue is that you are using an "ad hoc", typeless input here
> > > for the "configure" operation. Because it's typeless, ARIA sends
> > > it "as is" and thus has no idea that what's inside might be a
> > > syntactical intrinsic function.
> > >
> > > I will open a big for this, but for now the workaround is to
> > > explicitly declare the input at the type, which I think is
> > > generally a good idea. (And actually, I would rather ARIA not
> > > allow the current typeless input
> > > situation.)
> > >
> > > Here's how it would look:
> > >
> > > tosca_definitions_version: tosca_simple_yaml_1_0
> > >
> > > data_types:
> > >
> > > Payload:
> > > properties:
> > > config:
> > > t
Re: Jenkins job on ariatosca-website failing after gitbox transition
Jenkins is back up, and the website has been built. John On Tue, Dec 5, 2017 at 12:13 PM John D. Ament wrote: > Ok, so there's a couple of issues. > Jenkins access is limited to those in a certain group, since its a single > jenkins instance for all projects without limited privileges. Right now I > have access to manage jobs in jenkins, but would be happy to add others who > need it. > > The jenkins job is something I set up, based on a cookie cutter I use to > automate website builds (jenkins job configuration for me is like bonsai > trimming). The job just executes the shell script in the repo. I just > need to repoint to gitbox to reenable the job, but right now jenkins is > down. When it comes back I'll get the job going again. > > I've assigned myself the infra ticket, please try to avoid sending them > issues that we should be able to fix ourselves (and discussing it on list > helps identify who or what can/should be fixed). > > John > > > On Tue, Dec 5, 2017 at 12:05 PM Thomas Nadeau > wrote: > >> i just realized that after the switch to gitbox, pushed PRs to the >> ariatosca-website repo are not triggering the Jenkins job which results in >> the site being re-generated and published to ariatosca.org >> >> >> [5:45] >> so my PR yesterday and @Miguel Jiménez’s from today while merged, are not >> yet reflected >> >> >> smarthi [5:49 PM] >> on other projects like OpenNLP, Flink, Beam etc… there’s a buildbot setup >> that triggers a build and regenerates the website >> >> >> Thomas Nadeau [5:54 PM] >> thats good, but I don't really want to set up a different automation >> trigger/builder if I can help it :sunglasses: >> >> >> [5:54] >> i did look into buildbot earlier before I knew there was an apache infra >> jenkins job setup >> >> >> [5:55] >> I suspect that its just not triggered properly because the triggers need >> to >> come from github now instead of apache git >> >> >> [5:55] >> so token generator is a one button situation on github, so infra prob >> needs >> to have a committer generate the token and the replace the old one with >> that >> >> >> smarthi [6:00 PM] >> well u can file Infra ticket to enable buildbot for aria-site >> >> >> Thomas Nadeau [6:04 PM] >> how does one file a ticket? >> >> [6:05] >> just email to infra@apache? >> >> >> smarthi [6:06 PM] >> jira >> >> >> Thomas Nadeau [6:06 PM] >> ah like the gitbox one >> >> >> smarthi [6:07 PM] >> yes >> >> >> Thomas Nadeau [6:08 PM] >> ill fire one up now >> >> >> johndament [6:23 PM] >> i can fix the jenkins job >> >
AriaTosca website published
The Apache Jenkins build system has built AriaTosca Website (build #38) Status: Successful Check console output at https://builds.apache.org/job/AriaTosca%20Website/38/ to view the results.
AriaTosca website published
The Apache Jenkins build system has built AriaTosca Website (build #37) Status: Fixed Check console output at https://builds.apache.org/job/AriaTosca%20Website/37/ to view the results.
Re: Jenkins job on ariatosca-website failing after gitbox transition
Ok, so there's a couple of issues. Jenkins access is limited to those in a certain group, since its a single jenkins instance for all projects without limited privileges. Right now I have access to manage jobs in jenkins, but would be happy to add others who need it. The jenkins job is something I set up, based on a cookie cutter I use to automate website builds (jenkins job configuration for me is like bonsai trimming). The job just executes the shell script in the repo. I just need to repoint to gitbox to reenable the job, but right now jenkins is down. When it comes back I'll get the job going again. I've assigned myself the infra ticket, please try to avoid sending them issues that we should be able to fix ourselves (and discussing it on list helps identify who or what can/should be fixed). John On Tue, Dec 5, 2017 at 12:05 PM Thomas Nadeau wrote: > i just realized that after the switch to gitbox, pushed PRs to the > ariatosca-website repo are not triggering the Jenkins job which results in > the site being re-generated and published to ariatosca.org > > > [5:45] > so my PR yesterday and @Miguel Jiménez’s from today while merged, are not > yet reflected > > > smarthi [5:49 PM] > on other projects like OpenNLP, Flink, Beam etc… there’s a buildbot setup > that triggers a build and regenerates the website > > > Thomas Nadeau [5:54 PM] > thats good, but I don't really want to set up a different automation > trigger/builder if I can help it :sunglasses: > > > [5:54] > i did look into buildbot earlier before I knew there was an apache infra > jenkins job setup > > > [5:55] > I suspect that its just not triggered properly because the triggers need to > come from github now instead of apache git > > > [5:55] > so token generator is a one button situation on github, so infra prob needs > to have a committer generate the token and the replace the old one with > that > > > smarthi [6:00 PM] > well u can file Infra ticket to enable buildbot for aria-site > > > Thomas Nadeau [6:04 PM] > how does one file a ticket? > > [6:05] > just email to infra@apache? > > > smarthi [6:06 PM] > jira > > > Thomas Nadeau [6:06 PM] > ah like the gitbox one > > > smarthi [6:07 PM] > yes > > > Thomas Nadeau [6:08 PM] > ill fire one up now > > > johndament [6:23 PM] > i can fix the jenkins job >
Jenkins job on ariatosca-website failing after gitbox transition
i just realized that after the switch to gitbox, pushed PRs to the ariatosca-website repo are not triggering the Jenkins job which results in the site being re-generated and published to ariatosca.org [5:45] so my PR yesterday and @Miguel Jiménez’s from today while merged, are not yet reflected smarthi [5:49 PM] on other projects like OpenNLP, Flink, Beam etc… there’s a buildbot setup that triggers a build and regenerates the website Thomas Nadeau [5:54 PM] thats good, but I don't really want to set up a different automation trigger/builder if I can help it :sunglasses: [5:54] i did look into buildbot earlier before I knew there was an apache infra jenkins job setup [5:55] I suspect that its just not triggered properly because the triggers need to come from github now instead of apache git [5:55] so token generator is a one button situation on github, so infra prob needs to have a committer generate the token and the replace the old one with that smarthi [6:00 PM] well u can file Infra ticket to enable buildbot for aria-site Thomas Nadeau [6:04 PM] how does one file a ticket? [6:05] just email to infra@apache? smarthi [6:06 PM] jira Thomas Nadeau [6:06 PM] ah like the gitbox one smarthi [6:07 PM] yes Thomas Nadeau [6:08 PM] ill fire one up now johndament [6:23 PM] i can fix the jenkins job
AriaTosca website published
The Apache Jenkins build system has built AriaTosca Website (build #36) Status: Failure Check console output at https://builds.apache.org/job/AriaTosca%20Website/36/ to view the results.
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 wrote:
> >
> > > There is a bug here, but it has nothing to do with SELF.
> > >
> > > The issue is that you are using an "ad hoc", typeless input here for
> > > the "configure" operation. Because it's typeless, ARIA sends it "as
> > > is" and thus has no idea that what's inside might be a syntactical
> > > intrinsic function.
> > >
> > > I will open a big for this, but for now the workaround is to
> > > explicitly declare the input at the type, which I think is generally
> > > a good idea. (And actually, I would rather ARIA not allow the
> > > current typeless input
> > > situation.)
> > >
> > > Here's how it would look:
> > >
> > > 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: test default value
> > > 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 10:58 AM, Vaishali Krishnamurthy <
> > > v.krishnamurt...@globallogic.com.invalid> wrote:
> > >
> > >> Here, I have used the get_attribute in the input defined in the
> > >> second level, for which it returns me the dictionary object.
> > >> inpu
RE: get_attribute function not supporting SELF as
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 wrote:
>
> > There is a bug here, but it has nothing to do with SELF.
> >
> > The issue is that you are using an "ad hoc", typeless input here for
> > the "configure" operation. Because it's typeless, ARIA sends it "as
> > is" and thus has no idea that what's inside might be a syntactical
> > intrinsic function.
> >
> > I will open a big for this, but for now the workaround is to
> > explicitly declare the input at the type, which I think is generally
> > a good idea. (And actually, I would rather ARIA not allow the
> > current typeless input
> > situation.)
> >
> > Here's how it would look:
> >
> > 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: test default value
> > 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 10:58 AM, Vaishali Krishnamurthy <
> > v.krishnamurt...@globallogic.com.invalid> wrote:
> >
> >> Here, I have used the get_attribute in the input defined in the
> >> second level, for which it returns me the dictionary object.
> >> inputs:
> >> payload: {
> >> "config": {get_attribute: [ SELF, vmme_configuration
> >> ]}}
> >>
> >> When I use the get_attribute in inputs defined in the first level
> >> it returns me none.
> >> inputs:
> >>config: {get_attribute: [ SELF, vmme_configuration ]}
> >>
> >> Please find the service template below.
> >> node_types:
> >> my_Node_Server:
> >> derived_from: tosca.nodes.Root
> >> attributes:
> >> vmme_configuration:
> >> type: string
> >> interfaces:
> >> Standard:
> >> create:
> >> implementation: sample > sample.sample_test.call_test
> >> inputs: {}
> >> configure:
> >> implementation: sample > sample.sample_test.call_name
> >> inputs: {}
> >>
> >> 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
> >> ]}
> >>
> >> Regards,
> >> Vaishali.
> >>
> >> -Original Message-
> >> From: Tal Liron [mailto:t...@cloudify.co]
> >> Sent: Tuesday, December 05, 2017 2:06 PM
> >> To: dev@ariatosca.incubator.apache.org
> >> Subject: Re: get_attribute function not supporting SELF as
> >>
> >>
> >> Thanks for the report. Do you possibly have
Podling Report Reminder - December 2017
Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 20 December 2017, 10:30 am PDT. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted 2 weeks before the board meeting, to allow sufficient time for review and submission (Wed, December 06). Please submit your report with sufficient time to allow the Incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is 2 weeks prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. * How does the podling rate their own maturity. This should be appended to the Incubator Wiki page at: https://wiki.apache.org/incubator/December2017 Note: This is manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC
Subscribe for dev mailing list
Hi, Am looking for subscription for dev@ariatosca.incubator.apache.org to have my queries posted to dev forum. Could you help with this ? Regards, Vaishali
Re: Subscribe for dev mailing list
Email dev-subscr...@ariatosca.apache.org Sent from my iPhone > On Dec 5, 2017, at 12:48 AM, Vaishali Krishnamurthy > wrote: > > Hi, > > > > Am looking for subscription for dev@ariatosca.incubator.apache.org to have > my queries posted to dev forum. > > Could you help with this ? > > > > Regards, > > Vaishali
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 wrote:
>
> > There is a bug here, but it has nothing to do with SELF.
> >
> > The issue is that you are using an "ad hoc", typeless input here for
> > the "configure" operation. Because it's typeless, ARIA sends it "as
> > is" and thus has no idea that what's inside might be a syntactical
> > intrinsic function.
> >
> > I will open a big for this, but for now the workaround is to
> > explicitly declare the input at the type, which I think is generally a
> > good idea. (And actually, I would rather ARIA not allow the current
> > typeless input
> > situation.)
> >
> > Here's how it would look:
> >
> > 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: test default value
> > 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 10:58 AM, Vaishali Krishnamurthy <
> > v.krishnamurt...@globallogic.com.invalid> wrote:
> >
> >> Here, I have used the get_attribute in the input defined in the
> >> second level, for which it returns me the dictionary object.
> >> inputs:
> >> payload: {
> >> "config": {get_attribute: [ SELF, vmme_configuration ]}}
> >>
> >> When I use the get_attribute in inputs defined in the first level it
> >> returns me none.
> >> inputs:
> >>config: {get_attribute: [ SELF, vmme_configuration ]}
> >>
> >> Please find the service template below.
> >> node_types:
> >> my_Node_Server:
> >> derived_from: tosca.nodes.Root
> >> attributes:
> >> vmme_configuration:
> >> type: string
> >> interfaces:
> >> Standard:
> >> create:
> >> implementation: sample > sample.sample_test.call_test
> >> inputs: {}
> >> configure:
> >> implementation: sample > sample.sample_test.call_name
> >> inputs: {}
> >>
> >> 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 ]}
> >>
> >> Regards,
> >> Vaishali.
> >>
> >> -Original Message-
> >> From: Tal Liron [mailto:t...@cloudify.co]
> >> Sent: Tuesday, December 05, 2017 2:06 PM
> >> To: dev@ariatosca.incubator.apache.org
> >> Subject: Re: get_attribute function not supporting SELF as
> >>
> >>
> >> Thanks for the report. Do you possibly have a minimal TOSCA template
> >> we can use to reproduce the error?
> >>
> >> On Tue, Dec 5, 2017 at 8:29 AM, Vaishali Krishnamurthy <
> >> v.krishnamurt...@globallogic.com.invalid> wrote:
> >>
> >> > Hi,
> >> >
> >> > We have observed the attribute resolution is not proper when we use
> >> > SELF as in get_attribute function and it
>
RE: get_attribute function not supporting SELF as
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 wrote:
> There is a bug here, but it has nothing to do with SELF.
>
> The issue is that you are using an "ad hoc", typeless input here for
> the "configure" operation. Because it's typeless, ARIA sends it "as
> is" and thus has no idea that what's inside might be a syntactical
> intrinsic function.
>
> I will open a big for this, but for now the workaround is to
> explicitly declare the input at the type, which I think is generally a
> good idea. (And actually, I would rather ARIA not allow the current
> typeless input
> situation.)
>
> Here's how it would look:
>
> 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: test default value
> 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 10:58 AM, Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com.invalid> wrote:
>
>> Here, I have used the get_attribute in the input defined in the
>> second level, for which it returns me the dictionary object.
>> inputs:
>> payload: {
>> "config": {get_attribute: [ SELF, vmme_configuration ]}}
>>
>> When I use the get_attribute in inputs defined in the first level it
>> returns me none.
>> inputs:
>>config: {get_attribute: [ SELF, vmme_configuration ]}
>>
>> Please find the service template below.
>> node_types:
>> my_Node_Server:
>> derived_from: tosca.nodes.Root
>> attributes:
>> vmme_configuration:
>> type: string
>> interfaces:
>> Standard:
>> create:
>> implementation: sample > sample.sample_test.call_test
>> inputs: {}
>> configure:
>> implementation: sample > sample.sample_test.call_name
>> inputs: {}
>>
>> 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 ]}
>>
>> Regards,
>> Vaishali.
>>
>> -Original Message-
>> From: Tal Liron [mailto:t...@cloudify.co]
>> Sent: Tuesday, December 05, 2017 2:06 PM
>> To: dev@ariatosca.incubator.apache.org
>> Subject: Re: get_attribute function not supporting SELF as
>>
>>
>> Thanks for the report. Do you possibly have a minimal TOSCA template
>> we can use to reproduce the error?
>>
>> On Tue, Dec 5, 2017 at 8:29 AM, Vaishali Krishnamurthy <
>> v.krishnamurt...@globallogic.com.invalid> wrote:
>>
>> > Hi,
>> >
>> > We have observed the attribute resolution is not proper when we use
>> > SELF as in get_attribute function and it
>> > works fine when we use the node name as .
>> > With SELF it takes the default value. Could you confirm if there is
>> > any fix for this issue ?
>> >
>> >
>> > Regards,
>> >
>> > Vaishali
>> >
>>
>
>
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 wrote:
> There is a bug here, but it has nothing to do with SELF.
>
> The issue is that you are using an "ad hoc", typeless input here for the
> "configure" operation. Because it's typeless, ARIA sends it "as is" and
> thus has no idea that what's inside might be a syntactical intrinsic
> function.
>
> I will open a big for this, but for now the workaround is to explicitly
> declare the input at the type, which I think is generally a good idea. (And
> actually, I would rather ARIA not allow the current typeless input
> situation.)
>
> Here's how it would look:
>
> 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: test default value
> 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 10:58 AM, Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com.invalid> wrote:
>
>> Here, I have used the get_attribute in the input defined in the second
>> level, for which it returns me the dictionary object.
>> inputs:
>> payload: {
>> "config": {get_attribute: [ SELF, vmme_configuration ]}}
>>
>> When I use the get_attribute in inputs defined in the first level it
>> returns
>> me none.
>> inputs:
>>config: {get_attribute: [ SELF, vmme_configuration ]}
>>
>> Please find the service template below.
>> node_types:
>> my_Node_Server:
>> derived_from: tosca.nodes.Root
>> attributes:
>> vmme_configuration:
>> type: string
>> interfaces:
>> Standard:
>> create:
>> implementation: sample > sample.sample_test.call_test
>> inputs: {}
>> configure:
>> implementation: sample > sample.sample_test.call_name
>> inputs: {}
>>
>> 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 ]}
>>
>> Regards,
>> Vaishali.
>>
>> -Original Message-
>> From: Tal Liron [mailto:t...@cloudify.co]
>> Sent: Tuesday, December 05, 2017 2:06 PM
>> To: dev@ariatosca.incubator.apache.org
>> Subject: Re: get_attribute function not supporting SELF as
>>
>>
>> Thanks for the report. Do you possibly have a minimal TOSCA template we
>> can
>> use to reproduce the error?
>>
>> On Tue, Dec 5, 2017 at 8:29 AM, Vaishali Krishnamurthy <
>> v.krishnamurt...@globallogic.com.invalid> wrote:
>>
>> > Hi,
>> >
>> > We have observed the attribute resolution is not proper when we use
>> > SELF as in get_attribute function and it
>> > works fine when we use the node name as .
>> > With SELF it takes the default value. Could you confirm if there is any
>> > fix for this issue ?
>> >
>> >
>> > Regards,
>> >
>> > Vaishali
>> >
>>
>
>
Re: get_attribute function not supporting SELF as
There is a bug here, but it has nothing to do with SELF.
The issue is that you are using an "ad hoc", typeless input here for the
"configure" operation. Because it's typeless, ARIA sends it "as is" and
thus has no idea that what's inside might be a syntactical intrinsic
function.
I will open a big for this, but for now the workaround is to explicitly
declare the input at the type, which I think is generally a good idea. (And
actually, I would rather ARIA not allow the current typeless input
situation.)
Here's how it would look:
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: test default value
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 10:58 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:
> Here, I have used the get_attribute in the input defined in the second
> level, for which it returns me the dictionary object.
> inputs:
> payload: {
> "config": {get_attribute: [ SELF, vmme_configuration ]}}
>
> When I use the get_attribute in inputs defined in the first level it
> returns
> me none.
> inputs:
>config: {get_attribute: [ SELF, vmme_configuration ]}
>
> Please find the service template below.
> node_types:
> my_Node_Server:
> derived_from: tosca.nodes.Root
> attributes:
> vmme_configuration:
> type: string
> interfaces:
> Standard:
> create:
> implementation: sample > sample.sample_test.call_test
> inputs: {}
> configure:
> implementation: sample > sample.sample_test.call_name
> inputs: {}
>
> 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 ]}
>
> Regards,
> Vaishali.
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, December 05, 2017 2:06 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: get_attribute function not supporting SELF as
>
>
> Thanks for the report. Do you possibly have a minimal TOSCA template we can
> use to reproduce the error?
>
> On Tue, Dec 5, 2017 at 8:29 AM, Vaishali Krishnamurthy <
> v.krishnamurt...@globallogic.com.invalid> wrote:
>
> > Hi,
> >
> > We have observed the attribute resolution is not proper when we use
> > SELF as in get_attribute function and it
> > works fine when we use the node name as .
> > With SELF it takes the default value. Could you confirm if there is any
> > fix for this issue ?
> >
> >
> > Regards,
> >
> > Vaishali
> >
>
RE: get_attribute function not supporting SELF as
Here, I have used the get_attribute in the input defined in the second
level, for which it returns me the dictionary object.
inputs:
payload: {
"config": {get_attribute: [ SELF, vmme_configuration ]}}
When I use the get_attribute in inputs defined in the first level it returns
me none.
inputs:
config: {get_attribute: [ SELF, vmme_configuration ]}
Please find the service template below.
node_types:
my_Node_Server:
derived_from: tosca.nodes.Root
attributes:
vmme_configuration:
type: string
interfaces:
Standard:
create:
implementation: sample > sample.sample_test.call_test
inputs: {}
configure:
implementation: sample > sample.sample_test.call_name
inputs: {}
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 ]}
Regards,
Vaishali.
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co]
Sent: Tuesday, December 05, 2017 2:06 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: get_attribute function not supporting SELF as
Thanks for the report. Do you possibly have a minimal TOSCA template we can
use to reproduce the error?
On Tue, Dec 5, 2017 at 8:29 AM, Vaishali Krishnamurthy <
v.krishnamurt...@globallogic.com.invalid> wrote:
> Hi,
>
> We have observed the attribute resolution is not proper when we use
> SELF as in get_attribute function and it
> works fine when we use the node name as .
> With SELF it takes the default value. Could you confirm if there is any
> fix for this issue ?
>
>
> Regards,
>
> Vaishali
>
Re: get_attribute function not supporting SELF as
Thanks for the report. Do you possibly have a minimal TOSCA template we can use to reproduce the error? On Tue, Dec 5, 2017 at 8:29 AM, Vaishali Krishnamurthy < v.krishnamurt...@globallogic.com.invalid> wrote: > Hi, > > We have observed the attribute resolution is not proper when we use SELF as > in get_attribute function and it works fine when > we use the node name as . With SELF it takes the > default value. Could you confirm if there is any fix for this issue ? > > > Regards, > > Vaishali >
