RE: [Discuss] Future of AriaTosca

[D Jayachandran]

Hi Tom,

Please forward the meeting invite to us.


Regards,
DJ

-Original Message-
From: Thomas Nadeau [mailto:tnad...@lucidvision.com] 
Sent: Thursday, May 17, 2018 3:30 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: [Discuss] Future of AriaTosca

I no longer have access to the “pro” Zoom account I had at Cloudify, so I’ll 
schedule this using BlueJeans which will host as many people as would like to 
join, and is as cross-platform compatible to Zoom.  I’ll send the invite out 
tomorrow morning.

—Tom


> On May 16, 2018, at 5:28 PM, Suneel Marthi <suneel.mar...@gmail.com> wrote:
> 
> On Wed, May 16, 2018 at 4:17 PM, Thomas Nadeau 
> <tnad...@lucidvision.com>
> wrote:
> 
>> 
>>I meant that he was 2 ahead of Israel.  *)
>> 
> 
> Neh... its 3.5 hrs ahead of Israel.
> 
>> 
>>Anyways… is Monday at 10AM EST cool for everyone?
>> 
> 
> Please go ahead and schedule the meeting, I'll not be available but 
> nevertheless go ahead without me.
> 
> 
>> 
>>> On May 16, 2018, at 11:44 AM, Suneel Marthi 
>>> <suneel.mar...@gmail.com>
>> wrote:
>>> 
>>> India is GMT + 5.5  (Indian culture is setup to handle Float types)
>>> 
>>> 
>>> 
>>> On Wed, May 16, 2018 at 10:40 AM, Thomas Nadeau 
>>> <tnad...@lucidvision.com
>>> 
>>> wrote:
>>> 
>>>> 
>>>>   Sorry to not respond to this thread; been very busy with my 
>>>> new gig.
>>>> 
>>>>   I am happy to setup a Zoom for this Thursday or Friday and 
>>>> take meeting minutes which will be published to this list/Slack.  
>>>> The challenge has always
>> been
>>>> the spanning
>>>> timezones.  Tal is in Central, I am EST and DJ is GMT+2 I think.
>>>> 
>>>>   I propose we book 10 or 11AM EST which is more or less in the 
>>>> center of those.
>>>> 
>>>>   —Tom
>>>> 
>>>> 
>>>>> On May 16, 2018, at 1:40 AM, Suneel Marthi 
>>>>> <suneel.mar...@gmail.com>
>>>> wrote:
>>>>> 
>>>>> DJ, if u could setup a call - please go ahead and do it - I really
>> don't
>>>>> have time for this given my day job.
>>>>> 
>>>>> If Tal and other committers could join the call and decide on 
>>>>> future
>>>> course
>>>>> of action that would be great.
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, May 16, 2018 at 1:30 AM, D Jayachandran <
>>>> d.jayachand...@ericsson.com
>>>>>> wrote:
>>>>> 
>>>>>> Hi Suneel,
>>>>>> 
>>>>>> We in Ericsson are actively working on ARIA. We want to keep the
>> project
>>>>>> on and community active.
>>>>>> It is just that we couldn't make any contribution because there 
>>>>>> is no active committer. I already contacted you regarding the same.
>>>>>> Could we setup a short call to discuss on this?
>>>>>> 
>>>>>> Thanks,
>>>>>> /DJ
>>>>>> 
>>>>>> -Original Message-
>>>>>> From: Suneel Marthi [mailto:smar...@apache.org]
>>>>>> Sent: Tuesday, May 15, 2018 11:53 PM
>>>>>> To: dev@ariatosca.incubator.apache.org
>>>>>> Subject: Re: [Discuss] Future of AriaTosca
>>>>>> 
>>>>>> Adding dev@ to the conversation.
>>>>>> 
>>>>>> On Mon, May 14, 2018 at 7:42 PM, Tal Liron <tal.li...@gmail.com>
>> wrote:
>>>>>> 
>>>>>>> Almost all the committers have moved on. Unless new contributors 
>>>>>>> want to come in and revive the efforts, the course of action seems 
>>>>>>> clear.
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, May 14, 2018 at 6:38 PM Suneel Marthi 
>>>>>>> <smar...@apache.org>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Given that the project's not seen any activity in like 3 months 
>>>>>>>> and the mail lists have gone dry - reviving this discussion 
>>>>>>>> again about the future of AriaTosca and what the next course of action 
>>>>>>>> is?
>>>>>>>> 
>>>>>>>> Thoughts/Comments ?
>>>>>>>> 
>>>>>>>> Suneel
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 

RE: [Discuss] Future of AriaTosca

[D Jayachandran]

Hi Suneel,

What is the meeting tool which is preferred. We usually use skype meeting calls.
Also can we have the meeting scheduled tomorrow. Could you please let me know 
your comfortable time for the meeting ?

Regards,
DJ
-Original Message-
From: Suneel Marthi [mailto:suneel.mar...@gmail.com] 
Sent: Wednesday, May 16, 2018 11:12 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: [Discuss] Future of AriaTosca

On Wed, May 16, 2018 at 1:38 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Suneel,
>
> Currently there is no pending PR's from my side. Earlier Tom and 
> myself used to have one to one discussion for merging a PR.
> We have many contributions pending from our side which we have made as 
> PR yet as we don’t have any committer to acknowledge and merge it I 
> can send those contributions as PR, if we have committers to review 
> and merge it.
>

That's the problem - all of the committers and PPMC have since moved away from 
the project and there's none to steer this forward.
Regardless please setup a call and let's decide on future course.


>
> Regards,
> DJ
>
> -Original Message-
> From: Suneel Marthi [mailto:smar...@apache.org]
> Sent: Wednesday, May 16, 2018 11:04 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: [Discuss] Future of AriaTosca
>
> Do u have any open PRs pending review ?  Would any of the present 
> PMC/committers have time to review and merge the PRs? @Tal and others ?
>
>
>
> On Wed, May 16, 2018 at 1:30 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Suneel,
> >
> > We in Ericsson are actively working on ARIA. We want to keep the 
> > project on and community active.
> > It is just that we couldn't make any contribution because there is 
> > no active committer. I already contacted you regarding the same.
> > Could we setup a short call to discuss on this?
> >
> > Thanks,
> > /DJ
> >
> > -Original Message-
> > From: Suneel Marthi [mailto:smar...@apache.org]
> > Sent: Tuesday, May 15, 2018 11:53 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: [Discuss] Future of AriaTosca
> >
> > Adding dev@ to the conversation.
> >
> > On Mon, May 14, 2018 at 7:42 PM, Tal Liron <tal.li...@gmail.com> wrote:
> >
> > > Almost all the committers have moved on. Unless new contributors 
> > > want to come in and revive the efforts, the course of action seems
> clear.
> > >
> > >
> > > On Mon, May 14, 2018 at 6:38 PM Suneel Marthi <smar...@apache.org>
> > wrote:
> > >
> > >> Given that the project's not seen any activity in like 3 months 
> > >> and the mail lists have gone dry - reviving this discussion again 
> > >> about the future of AriaTosca and what the next course of action is?
> > >>
> > >> Thoughts/Comments ?
> > >>
> > >> Suneel
> > >>
> > >
> >
>

RE: [Discuss] Future of AriaTosca

[D Jayachandran]

Hi Suneel,

Currently there is no pending PR's from my side. Earlier Tom and myself used to 
have one to one discussion for merging a PR.
We have many contributions pending from our side which we have made as PR yet 
as we don’t have any committer to acknowledge and merge it
I can send those contributions as PR, if we have committers to review and merge 
it.

Regards,
DJ

-Original Message-
From: Suneel Marthi [mailto:smar...@apache.org] 
Sent: Wednesday, May 16, 2018 11:04 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: [Discuss] Future of AriaTosca

Do u have any open PRs pending review ?  Would any of the present 
PMC/committers have time to review and merge the PRs? @Tal and others ?



On Wed, May 16, 2018 at 1:30 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Suneel,
>
> We in Ericsson are actively working on ARIA. We want to keep the 
> project on and community active.
> It is just that we couldn't make any contribution because there is no 
> active committer. I already contacted you regarding the same.
> Could we setup a short call to discuss on this?
>
> Thanks,
> /DJ
>
> -Original Message-
> From: Suneel Marthi [mailto:smar...@apache.org]
> Sent: Tuesday, May 15, 2018 11:53 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: [Discuss] Future of AriaTosca
>
> Adding dev@ to the conversation.
>
> On Mon, May 14, 2018 at 7:42 PM, Tal Liron <tal.li...@gmail.com> wrote:
>
> > Almost all the committers have moved on. Unless new contributors 
> > want to come in and revive the efforts, the course of action seems clear.
> >
> >
> > On Mon, May 14, 2018 at 6:38 PM Suneel Marthi <smar...@apache.org>
> wrote:
> >
> >> Given that the project's not seen any activity in like 3 months and 
> >> the mail lists have gone dry - reviving this discussion again about 
> >> the future of AriaTosca and what the next course of action is?
> >>
> >> Thoughts/Comments ?
> >>
> >> Suneel
> >>
> >
>

RE: [Discuss] Future of AriaTosca

[D Jayachandran]

Hi Suneel,

We in Ericsson are actively working on ARIA. We want to keep the project on and 
community active. 
It is just that we couldn't make any contribution because there is no active 
committer. I already contacted you regarding the same. 
Could we setup a short call to discuss on this?

Thanks,
/DJ

-Original Message-
From: Suneel Marthi [mailto:smar...@apache.org] 
Sent: Tuesday, May 15, 2018 11:53 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: [Discuss] Future of AriaTosca

Adding dev@ to the conversation.

On Mon, May 14, 2018 at 7:42 PM, Tal Liron  wrote:

> Almost all the committers have moved on. Unless new contributors want 
> to come in and revive the efforts, the course of action seems clear.
>
>
> On Mon, May 14, 2018 at 6:38 PM Suneel Marthi  wrote:
>
>> Given that the project's not seen any activity in like 3 months and 
>> the mail lists have gone dry - reviving this discussion again about 
>> the future of AriaTosca and what the next course of action is?
>>
>> Thoughts/Comments ?
>>
>> Suneel
>>
>

RE: [aria] TOSCA YAML Profile version and Support for Topology Substitution

[D Jayachandran]

Hi Steve,

Please find answers below from my side.

- Can you confirm all versions of ARIA up to the latest release (i.e. 
apache-ariatosca 0.2.0) only support TOSCA YAML Profile 1.0?
  [DJ] - Yes, ARIA is yet to support TOSCA YAML profile 1.1. We are in the 
process of identifying the items for supporting TOSCA YAML profile 1.1
- Does apache-ariatosca 0.2.0 (or earlier release) support topology 
substitution defined in TOSCA YAML Profile 1.0?
  [DJ] - Nope
- When will ARIA support topology substitution defined in TOSCA YAML Profile 
1.0?
  [DJ] - I need to discuss with tom, on contributing this from our side.
- When will ARIA support TOSCA YAML Profile 1.1?
  [DJ] -  I will let tom, answer this.


Regards,
DJ
-Original Message-
From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com] 
Sent: Monday, March 26, 2018 6:40 AM
To: tnadeaua...@gmail.com
Cc: dev@ariatosca.incubator.apache.org
Subject: [aria] TOSCA YAML Profile version and Support for Topology Substitution

Hi Tom

Sorry I lost track of the plans if any for supporting topology substitution 
defined in TOSCA YAML Profile 1.0 and TOSCA YAML Profile 1.0 (all features).
Here are a few questions:

- Can you confirm all versions of ARIA up to the latest release (i.e. 
apache-ariatosca 0.2.0) only support TOSCA YAML Profile 1.0?
- Does apache-ariatosca 0.2.0 (or earlier release) support topology 
substitution defined in TOSCA YAML Profile 1.0?
- When will ARIA support topology substitution defined in TOSCA YAML Profile 
1.0?
- When will ARIA support TOSCA YAML Profile 1.1?

Thank you

Regards
Steve B

RE: ARIA-118 plugin.yaml importing

[D Jayachandran]

Hi,

I have update the confluence with some details for "type-definitions". This is 
for the below JIRA story.
https://cwiki.apache.org/confluence/display/ARIATOSCA/Type+definitions 


Regards,
DJ

-Original Message-----
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Monday, February 19, 2018 7:29 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: ARIA-118 plugin.yaml importing

Hi All,

I have created the below JIRA story as updated below.

https://issues.apache.org/jira/browse/ARIA-438 


Regards,
DJ

-Original Message-----
From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
Sent: Monday, February 12, 2018 8:29 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: ARIA-118 plugin.yaml importing

Hi All,

As discussed, The PR is submitted for the 1st point mentioned in ARIA-118.
I would be creating 2 separate JIRA stories for the points 2 & 3 and 
contributing it.

Regards,
DJ
-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
Sent: Friday, December 08, 2017 2:14 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: ARIA-118 plugin.yaml importing

Hi Tal,

Do you have any comments for this PR ? And can you also share your comments for 
my proposal to handle global TOSCA type definitions.

Regards,
DJ
-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
Sent: Thursday, December 07, 2017 11:50 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: ARIA-118 plugin.yaml importing

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 <tnadeaua...@gmail.com> 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
> >
> > ht

RE: Aria support for TOSCA-simple-1.1

[D Jayachandran]

Hi,

I have updated the workspace with Changes/Updates between Simple Profile 1.0 to 
Simple Profile 1.1.
We can start to have discussions starting with that content.

Regards,
DJ

-Original Message-
From: Sudhakar Reddy [mailto:sudhakar.re...@amdocs.com] 
Sent: Tuesday, March 13, 2018 11:53 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Aria support for TOSCA-simple-1.1

Hi,

Please find the below details which I used for registration.

Confluence User Id: sudhakarreddy
Jira User id: Sudhakar53
Email: sudhakarreddy...@gmail.com

Note: I'm using my personal email address for contribution purpose.

Thanks & Regards
Sudhakar Reddy
Contact No:8758383421

-Original Message-
From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
Sent: Monday, March 12, 2018 7:21 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Aria support for TOSCA-simple-1.1

I don't seen you listed in any roles here:

https://issues.apache.org/jira/plugins/servlet/project-config/ARIA/roles

This means you need to go and first create an account for yourself on 
Confluence and let me know what the UID is. I can change the permissions then.

Also note that the Apache infra doesn't have a single signon across all of the 
platforms used here, so you need to create accounts on Jira (and git of
course) separately.

--tom


On Wed, Mar 7, 2018 at 11:36 PM, Sudhakar Reddy <sudhakar.re...@amdocs.com>
wrote:

> Hi Thomas,
> My email Id is : sudhakarreddy...@gmail.com
>
> Let me know once u add me. I'll update the findings in Confluence.
>
> Thanks & Regards
> Sudhakar Reddy
> Contact No:8758383421
>
>
> -Original Message-
> From: Thomas Nadeau [mailto:tnad...@lucidvision.com]
> Sent: Wednesday, March 07, 2018 10:15 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Aria support for TOSCA-simple-1.1
>
> What is your ID on confluence? I can add contributor permissions.
>
> > On Mar 7, 2018, at 11:29 AM, Sudhakar Reddy 
> > <sudhakar.re...@amdocs.com>
> wrote:
> >
> > Yeah. I'll check for the changes that are being made in 1.1 version.
> Btw, I don’t have any rights to create a page in Confluence.
> >
> > Probably I'll share the document after initial investigation.
> >
> >
> > Thanks & Regards
> > Sudhakar Reddy
> > Contact No:8758383421
> >
> >
> > -Original Message-
> > From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
> > Sent: Wednesday, March 07, 2018 5:55 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Aria support for TOSCA-simple-1.1
> >
> > I agree. This is specifically why I created the area on the wiki
> yesterday. Sudhakar, there is no need to start with python code 
> changes. If you can start by documenting what you think are the diffs 
> in the specs and any other requirements for changes, that is a great place to 
> start.
> >
> > Tal, welcome back to the party! 8)
> >
> > --Tom
> >
> >
> >
> > On Wed, Mar 7, 2018 at 3:43 AM, Tal Liron <tal.li...@gmail.com> wrote:
> >
> >> I'm willing to help with this effort is someone can get it started.
> >>
> >> What we really need is to spec this out -- can you start by 
> >> documenting on the wiki all the changes that ARIA would need to 
> >> support 1.1? Once we have that, we can turn it into JIRA tasks that
> individuals can handle.
> >>
> >> On Wed, Mar 7, 2018 at 2:27 AM, Sudhakar Reddy 
> >> <sudhakar.re...@amdocs.com>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm new to python and aria. So, it'll be difficult for me to 
> >>> design/implement this without getting some knowledge on how the 
> >>> YAML specification is been converted.
> >>>
> >>> I would like to be part of it if I can get inputs on how the 
> >>> approach should be.
> >>>
> >>> Thanks & Regards
> >>> Sudhakar Reddy
> >>> Contact No:8758383421
> >>>
> >>> -Original Message-
> >>> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> >>> Sent: Tuesday, March 06, 2018 12:23 PM
> >>> To: dev@ariatosca.incubator.apache.org
> >>> Subject: RE: Aria support for TOSCA-simple-1.1
> >>>
> >>> Hi Sudhakar,
> >>>
> >>> Am representing ericsson here and we would also like to have the 
> >>> support for simple YAML 1.1 with ARIA at the earliest.
> >>> It would be great if you can even contribute in making ARIA 
> >>> compliant to simple YAML 1.1 so that the support would be 
> >>&g

RE: Today's Grooming Meeting Reminder

[D Jayachandran]

Sure Tom

-Original Message-
From: Thomas Nadeau [mailto:tnadeaua...@gmail.com] 
Sent: Monday, March 12, 2018 7:32 PM
To: dev@ariatosca.incubator.apache.org
Subject: Today's Grooming Meeting Reminder

See you all at the grooming in an hour.  A reminder, these are the
coordinates:

https://cloudify.zoom.us/j/5055197842


I was hoping to discuss the Tosca 1.1 enhancements today that have been 
discussed on the mailer.

--Tom

RE: Aria support for TOSCA-simple-1.1

[D Jayachandran]

Yeah, sure I have gathered some information on the changes in 1.1 and I will 
update the same in confluence.

Regards,
DJ

-Original Message-
From: Sudhakar Reddy [mailto:sudhakar.re...@amdocs.com] 
Sent: Wednesday, March 07, 2018 9:59 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Aria support for TOSCA-simple-1.1

Yeah. I'll check for the changes that are being made in 1.1 version. Btw, I 
don’t have any rights to create a page in Confluence.

Probably I'll share the document after initial investigation.


Thanks & Regards
Sudhakar Reddy
Contact No:8758383421


-Original Message-
From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
Sent: Wednesday, March 07, 2018 5:55 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Aria support for TOSCA-simple-1.1

I agree. This is specifically why I created the area on the wiki yesterday. 
Sudhakar, there is no need to start with python code changes. If you can start 
by documenting what you think are the diffs in the specs and any other 
requirements for changes, that is a great place to start.

Tal, welcome back to the party! 8)

--Tom



On Wed, Mar 7, 2018 at 3:43 AM, Tal Liron <tal.li...@gmail.com> wrote:

> I'm willing to help with this effort is someone can get it started.
>
> What we really need is to spec this out -- can you start by 
> documenting on the wiki all the changes that ARIA would need to 
> support 1.1? Once we have that, we can turn it into JIRA tasks that 
> individuals can handle.
>
> On Wed, Mar 7, 2018 at 2:27 AM, Sudhakar Reddy 
> <sudhakar.re...@amdocs.com>
> wrote:
>
> > Hi,
> >
> > I'm new to python and aria. So, it'll be difficult for me to 
> > design/implement this without getting some knowledge on how the YAML 
> > specification is been converted.
> >
> > I would like to be part of it if I can get inputs on how the 
> > approach should be.
> >
> > Thanks & Regards
> > Sudhakar Reddy
> > Contact No:8758383421
> >
> > -Original Message-
> > From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> > Sent: Tuesday, March 06, 2018 12:23 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: Aria support for TOSCA-simple-1.1
> >
> > Hi Sudhakar,
> >
> > Am representing ericsson here and we would also like to have the 
> > support for simple YAML 1.1 with ARIA at the earliest.
> > It would be great if you can even contribute in making ARIA 
> > compliant to simple YAML 1.1 so that the support would be available soon.
> > Please share your thoughts over this.
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Sudhakar Reddy [mailto:sudhakar.re...@amdocs.com]
> > Sent: Thursday, March 01, 2018 10:46 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Aria support for TOSCA-simple-1.1
> >
> > Hi,
> >
> > I want to know whether we are in the process of giving the support 
> > for TOSCA definition: simple_yaml_1_1?
> >
> > As currently ONAP uses 1.1 version yaml to create the service model, 
> > the same won't be validated by aria. Let me know your inputs on this.
> >
> > Thanks & Regards
> > Sudhakar Reddy
> > Contact No:8758383421
> >
> > This message and the information contained herein is proprietary and 
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at https://www.amdocs.com/about/email-disclaimer < 
> > https://www.amdocs.com/about/email-disclaimer>
> > This message and the information contained herein is proprietary and 
> > confidential and subject to the Amdocs policy statement,
> >
> > you may review at https://www.amdocs.com/about/email-disclaimer < 
> > https://www.amdocs.com/about/email-disclaimer>
> >
> >
>
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 
<https://www.amdocs.com/about/email-disclaimer>

RE: Aria support for TOSCA-simple-1.1

[D Jayachandran]

Hi Sudhakar,

Am representing ericsson here and we would also like to have the support for 
simple YAML 1.1 with ARIA at the earliest.
It would be great if you can even contribute in making ARIA compliant to simple 
YAML 1.1 so that the support would be available soon.
Please share your thoughts over this.

Regards,
DJ

-Original Message-
From: Sudhakar Reddy [mailto:sudhakar.re...@amdocs.com] 
Sent: Thursday, March 01, 2018 10:46 AM
To: dev@ariatosca.incubator.apache.org
Subject: Aria support for TOSCA-simple-1.1

Hi,

I want to know whether we are in the process of giving the support for TOSCA 
definition: simple_yaml_1_1?

As currently ONAP uses 1.1 version yaml to create the service model, the same 
won't be validated by aria. Let me know your inputs on this.

Thanks & Regards
Sudhakar Reddy
Contact No:8758383421

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

RE: Validate csar file in Aria-0.1.1

[D Jayachandran]

Hi Sudhakar,

Thanks for raising this issue. Do you mean we are not extracting the CSAR as 
such ?

Regards,
DJ
From: Sudhakar Reddy [mailto:sudhakar.re...@amdocs.com]
Sent: Wednesday, February 28, 2018 5:34 PM
To: dev@ariatosca.incubator.apache.org
Subject: Validate csar file in Aria-0.1.1

Hi,

I'm trying to validate & store the service-template which is a csar extension 
file.

The actual service template is available under Definitions folder and is not 
present on the root folder. Even the Metadata present in 
TOSCA.meta:Entry-Definitions defines the path of the service-template to be 
inside Definitions folder.

But when I checked the aria code, we are taking the service template file name 
and checking on the root directory where the csar extracted. Why don't we 
consider the template  which is under Definitions/ ??

[X][cid:image002.png@01D3B0BA.619D22D0]

Thanks & Regards
Sudhakar Reddy
Contact No:8758383421

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer

RE: Implementation for get_operation_output

[D Jayachandran]

Hi All,

Please find my proposal for the implementation of "get_operation_output"

Proposal

1) To include attribute "outputs" for the "operation" model
2) Provide the operation as Instrumented operation with Node operation 
context and Relationship operation context(ctx).
3) Set any operation specific variable using the provided context(ctx) 
as "ctx.outputs["variable_1"] = "value"
4) Retrieve the stored value using get_operation_output from the 
associated operation model.

Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, November 13, 2017 8:29 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Implementation for get_operation_output

No, it has not yet been implemented.

On Mon, Nov 13, 2017 at 2:03 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Tal,
>
> Will the below work at this moment ?
>
> ctx return my_value = this is the value And then you could use 
> get_operation_output on "my_value".
>
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, November 09, 2017 10:14 PM
> To: dev@ariatosca.incubator.apache.org
> Cc: Paul Doyle <paul.do...@ericsson.com>; Barry Downey < 
> barry.dow...@ericsson.com>
> Subject: Re: Implementation for get_operation_output
>
> This function has not yet been implemented, so it's stored nowhere. 
> But of course it will likely have to be stored per particular execution.
>
> The "ctx" tool is just a way to remotely access the context object, so 
> yes, with plugins it's identical.
>
> On Thu, Nov 9, 2017 at 1:14 AM, D Jayachandran < 
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Tal,
> >
> > To understand a bit more, so where are these return values stored ?
> > Would they updated to services as we do with TOSCA attributes or do 
> > they live only for a particular execution ?
> > Also when it comes to plugin, can I do the same with the context 
> > object being passed rather than using the "ctx" tool ?
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Wednesday, November 08, 2017 8:06 PM
> > To: dev@ariatosca.incubator.apache.org
> > Cc: Paul Doyle <paul.do...@ericsson.com>; Barry Downey < 
> > barry.dow...@ericsson.com>
> > Subject: Re: Implementation for get_operation_output
> >
> > ARIA currently uses a special tool, called "ctx", to communicate 
> > with implementation scripts. I imagine we will use the same tool to 
> > set return values.
> >
> > My understanding is also that these return values are quite 
> > arbitrary, and thus un-typed. They will likely be stored as strings. 
> > So, for example, from within a bash script you would do something like this:
> >
> > ctx return my_value = this is the value
> >
> > And then you could use get_operation_output on "my_value".
> >
> >
> > On Tue, Nov 7, 2017 at 5:55 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com>
> > wrote:
> >
> > > Hi All,
> > >
> > > We currently don't have an implementation for the intrinsic 
> > > function "get_operation_output".
> > >
> > > As per the TOSCA Simple YAML 1.0, specification it indicates this 
> > > function must be used to retrieve the values of variables exposed 
> > > / exported from an interface operation.
> > > The variable which is referenced here seems to be an environmental 
> > > variable exposed by the interface operation script/plugin. (2.14.3
> > Example:
> > > setting output variables to an attribute, 2.14.4 Example: passing 
> > > output variables between operations )
> > >
> > > We would like if you have the same understanding on the variable 
> > > which is referenced in "get_operation_output".
> > >
> > > FROM TOSCA SPEC
> > >
> > >  - The required name of the variable that is 
> > > exposed / exported by the operation.
> > >
> > > Here it is just stated as a variable. In the example it is 
> > > mentioned as "environmental" variable exposed. Do you see a difference 
> > > here ?
> > > Are we considering as an environmental variable or as an attribute
> > variable ?.
> > >
> > > Please let us know your comments on this so that we can plan the 
> > > implementation of this.
> > >
> > > Regards,
> > > DJ
> > >
> >
>

RE: ARIA-118 plugin.yaml importing

[D Jayachandran]

Hi All,

I have created the below JIRA story as updated below.

https://issues.apache.org/jira/browse/ARIA-438 


Regards,
DJ

-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Monday, February 12, 2018 8:29 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: ARIA-118 plugin.yaml importing

Hi All,

As discussed, The PR is submitted for the 1st point mentioned in ARIA-118.
I would be creating 2 separate JIRA stories for the points 2 & 3 and 
contributing it.

Regards,
DJ
-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
Sent: Friday, December 08, 2017 2:14 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: ARIA-118 plugin.yaml importing

Hi Tal,

Do you have any comments for this PR ? And can you also share your comments for 
my proposal to handle global TOSCA type definitions.

Regards,
DJ
-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
Sent: Thursday, December 07, 2017 11:50 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: ARIA-118 plugin.yaml importing

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 <tnadeaua...@gmail.com> 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 
> > <d.jayachand...@ericsson.com>
> > 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: ARIA-118 plugin.yaml importing

[D Jayachandran]

Hi All,

As discussed, The PR is submitted for the 1st point mentioned in ARIA-118.
I would be creating 2 separate JIRA stories for the points 2 & 3 and 
contributing it.

Regards,
DJ
-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Friday, December 08, 2017 2:14 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: ARIA-118 plugin.yaml importing

Hi Tal,

Do you have any comments for this PR ? And can you also share your comments for 
my proposal to handle global TOSCA type definitions.

Regards,
DJ
-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
Sent: Thursday, December 07, 2017 11:50 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: ARIA-118 plugin.yaml importing

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 <tnadeaua...@gmail.com> 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 
> > <d.jayachand...@ericsson.com>
> > 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: Grooming Reminder

[D Jayachandran]

Ok.. Thanks Tom.

Regards,
DJ

-Original Message-
From: Thomas Nadeau [mailto:tnadeaua...@gmail.com] 
Sent: Monday, February 12, 2018 7:24 PM
To: dev@ariatosca.incubator.apache.org
Subject: Grooming Reminder

Team:

Just a reminder that we are now having not one but TWO grooming meetings on
Mondays: 9AM EST and 11AM EST.  The Zoom meeting info is the same for both:

https://cloudify.zoom.us/j/5055197842


See you online.

--Tom

Confluence wiki page write access

[D Jayachandran]

Hi All,

I would like to write up in the wiki for all the major PR's which am 
contributing.
Could you please provide me with the write access for it.


Regards,
DJ

RE: Grooming Meeting Minutes: January 22, 2018

[D Jayachandran]

Thanks Tom, I will be connecting

-Original Message-
From: Thomas Nadeau [mailto:tnad...@apache.org] 
Sent: Monday, February 05, 2018 5:47 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Grooming Meeting Minutes: January 22, 2018

We can use my personal Zoom for this morning's meeting:

https://cloudify.zoom.us/j/5055197842


On Mon, Feb 5, 2018 at 4:06 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Tom,
>
> Is it the same meeting invite which Miguel shared ?
>
> Regards,
> DJ
>
> -Original Message-
> From: Thomas Nadeau [mailto:tnad...@apache.org]
> Sent: Wednesday, January 31, 2018 7:23 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Grooming Meeting Minutes: January 22, 2018
>
> I can make it at 9AM EST on Monday.  If that works for you lets go for it.
> Anyone else that would like to attend then either in addition to our 
> regular time at 11AM EST or instead of is of course welcome to join 
> us. Ill still post meeting minutes, etc...
>
> --Tom
>
>
> On Wed, Jan 31, 2018 at 3:24 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Tom,
> >
> > Can we have the meeting scheduled by 9AM on Monday ?
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
> > Sent: Tuesday, January 30, 2018 6:25 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Grooming Meeting Minutes: January 22, 2018
> >
> > Fantastic. Can you please propose some times on Monday?  From my end 
> > I can be available from 8-11AM EST on Monday (then we have the other
> grooming).
> > If Monday doesnt work, please
> > look at Tuesdays at the same time range.
> >
> > --Tom
> >
> >
> > On Mon, Jan 29, 2018 at 7:44 PM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi,
> > >
> > > Even am fine with two meetings. Please let me know the timeslot 
> > > which can work for us.
> > >
> > > Regards,
> > > DJ
> > >
> > > -Original Message-
> > > From: Miguel Angel Jimenez Achinte 
> > > [mailto:mig...@rigiresearch.com]
> > > Sent: Monday, January 29, 2018 9:30 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Grooming Meeting Minutes: January 22, 2018
> > >
> > > Hi everyone,
> > > I'm fine with having two grooming meetings. I'd continue joining 
> > > at 11:00AM EST though.
> > > Cheers,
> > > Miguel
> > >
> > > On Thu, Jan 25, 2018 at 4:34 AM, Thomas Nadeau 
> > > <tnadeaua...@gmail.com>
> > > wrote:
> > >
> > > >
> > > > Hi guys,
> > > >
> > > > I wanted to discuss the time of the weekly grooming 
> > > > meeting and possibly options for how
> > > > to include everyone - because that is the goal here.   The time
> > currently
> > > > used was chosen because
> > > > it was not too early for people in PST (Miguel) GMT-8 and CST
> > > > (Tal) as well as to include people in the Israel Time Zone 
> > > > (GMT+2).  This is why 11AM EST (4PM GMT) was chosen - its not 
> > > > too late for people in the eastern zones, and not too early for 
> > > > those in the most western
> > zones.
> > > > Your time zone is 9 hours ahead of EST if I am not mistaken, 
> > > > which is going to probably be quite difficult to add to the mix, 
> > > > but if others are willing to meet earlier or later, thats fine with me.
> > > >
> > > > I wanted to propose another option: we have two grooming
> > > meetings.
> > > > I know that is not ideal,
> > > > but it at least means that everyone can attend one of these.  I 
> > > > can make both because I am sitting in the middle of all of these 
> > > > time zones, so I could keep continuity between meetings.  Of 
> > > > course, we will also ensure that all meeting minutes/decisions 
> > > > are echoed to the list as Apache requires.
> > > >
> > > > When we meet is up to the community here, so please 
> > > > discuss the options I proposed or suggest others so that we 
> > > > might arrive at something we can start with next week.
> > > >
> > > > Cheers,
> > > >
> > > >     —Tom
> > > >
> > > >
> > > > > O

RE: Grooming Meeting Minutes: January 22, 2018

[D Jayachandran]

Hi Tom,

Is it the same meeting invite which Miguel shared ?

Regards,
DJ

-Original Message-
From: Thomas Nadeau [mailto:tnad...@apache.org] 
Sent: Wednesday, January 31, 2018 7:23 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Grooming Meeting Minutes: January 22, 2018

I can make it at 9AM EST on Monday.  If that works for you lets go for it.
Anyone else that would like to attend then either in addition to our regular 
time at 11AM EST or instead of is of course welcome to join us. Ill still post 
meeting minutes, etc...

--Tom


On Wed, Jan 31, 2018 at 3:24 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Tom,
>
> Can we have the meeting scheduled by 9AM on Monday ?
>
> Regards,
> DJ
>
> -Original Message-
> From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
> Sent: Tuesday, January 30, 2018 6:25 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Grooming Meeting Minutes: January 22, 2018
>
> Fantastic. Can you please propose some times on Monday?  From my end I 
> can be available from 8-11AM EST on Monday (then we have the other grooming).
> If Monday doesnt work, please
> look at Tuesdays at the same time range.
>
> --Tom
>
>
> On Mon, Jan 29, 2018 at 7:44 PM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > Even am fine with two meetings. Please let me know the timeslot 
> > which can work for us.
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Miguel Angel Jimenez Achinte [mailto:mig...@rigiresearch.com]
> > Sent: Monday, January 29, 2018 9:30 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Grooming Meeting Minutes: January 22, 2018
> >
> > Hi everyone,
> > I'm fine with having two grooming meetings. I'd continue joining at 
> > 11:00AM EST though.
> > Cheers,
> > Miguel
> >
> > On Thu, Jan 25, 2018 at 4:34 AM, Thomas Nadeau 
> > <tnadeaua...@gmail.com>
> > wrote:
> >
> > >
> > > Hi guys,
> > >
> > > I wanted to discuss the time of the weekly grooming 
> > > meeting and possibly options for how
> > > to include everyone - because that is the goal here.   The time
> currently
> > > used was chosen because
> > > it was not too early for people in PST (Miguel) GMT-8 and CST 
> > > (Tal) as well as to include people in the Israel Time Zone 
> > > (GMT+2).  This is why 11AM EST (4PM GMT) was chosen - its not too 
> > > late for people in the eastern zones, and not too early for those 
> > > in the most western
> zones.
> > > Your time zone is 9 hours ahead of EST if I am not mistaken, which 
> > > is going to probably be quite difficult to add to the mix, but if 
> > > others are willing to meet earlier or later, thats fine with me.
> > >
> > > I wanted to propose another option: we have two grooming
> > meetings.
> > > I know that is not ideal,
> > > but it at least means that everyone can attend one of these.  I 
> > > can make both because I am sitting in the middle of all of these 
> > > time zones, so I could keep continuity between meetings.  Of 
> > > course, we will also ensure that all meeting minutes/decisions are 
> > > echoed to the list as Apache requires.
> > >
> > > When we meet is up to the community here, so please 
> > > discuss the options I proposed or suggest others so that we might 
> > > arrive at something we can start with next week.
> > >
> > > Cheers,
> > >
> > > —Tom
> > >
> > >
> > > > On Jan 24, 2018, at 2:07 AM, Miguel Angel Jimenez Achinte <
> > > mig...@rigiresearch.com> wrote:
> > > >
> > > > Hi DJ,
> > > >
> > > > This is the Zoom link to join the meeting:
> > > > https://cloudify.zoom.us/j/5055197842
> > > > The meeting currently being scheduled at 11:00AM EST, on Mondays.
> > > > That would be 1:00AM in your timezone?
> > > >
> > > > I leave it to Tom or someone else to discuss about possibly 
> > > > moving the meeting to another time.
> > > >
> > > > Regards,
> > > > Miguel
> > > >
> > > > --
> > > > Miguel Jimenez, PhD student
> > > > Department of Computer Science
> > > > University of Victoria
> > > > Engineering/Computer Science Building (ECS), Room 412 Victoria, 
> > > > BC V8W 3p6 Canada
> > > &g

RE: Grooming Meeting Minutes: January 22, 2018

[D Jayachandran]

Hi Tom,

Can we have the meeting scheduled by 9AM on Monday ?

Regards,
DJ

-Original Message-
From: Thomas Nadeau [mailto:tnadeaua...@gmail.com] 
Sent: Tuesday, January 30, 2018 6:25 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Grooming Meeting Minutes: January 22, 2018

Fantastic. Can you please propose some times on Monday?  From my end I can be 
available from 8-11AM EST on Monday (then we have the other grooming).
If Monday doesnt work, please
look at Tuesdays at the same time range.

--Tom


On Mon, Jan 29, 2018 at 7:44 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> Even am fine with two meetings. Please let me know the timeslot which 
> can work for us.
>
> Regards,
> DJ
>
> -Original Message-
> From: Miguel Angel Jimenez Achinte [mailto:mig...@rigiresearch.com]
> Sent: Monday, January 29, 2018 9:30 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Grooming Meeting Minutes: January 22, 2018
>
> Hi everyone,
> I'm fine with having two grooming meetings. I'd continue joining at 
> 11:00AM EST though.
> Cheers,
> Miguel
>
> On Thu, Jan 25, 2018 at 4:34 AM, Thomas Nadeau <tnadeaua...@gmail.com>
> wrote:
>
> >
> > Hi guys,
> >
> > I wanted to discuss the time of the weekly grooming meeting 
> > and possibly options for how
> > to include everyone - because that is the goal here.   The time currently
> > used was chosen because
> > it was not too early for people in PST (Miguel) GMT-8 and CST (Tal) 
> > as well as to include people in the Israel Time Zone (GMT+2).  This 
> > is why 11AM EST (4PM GMT) was chosen - its not too late for people 
> > in the eastern zones, and not too early for those in the most western zones.
> > Your time zone is 9 hours ahead of EST if I am not mistaken, which 
> > is going to probably be quite difficult to add to the mix, but if 
> > others are willing to meet earlier or later, thats fine with me.
> >
> > I wanted to propose another option: we have two grooming
> meetings.
> > I know that is not ideal,
> > but it at least means that everyone can attend one of these.  I can 
> > make both because I am sitting in the middle of all of these time 
> > zones, so I could keep continuity between meetings.  Of course, we 
> > will also ensure that all meeting minutes/decisions are echoed to 
> > the list as Apache requires.
> >
> > When we meet is up to the community here, so please discuss 
> > the options I proposed or suggest others so that we might arrive at 
> > something we can start with next week.
> >
> > Cheers,
> >
> > —Tom
> >
> >
> > > On Jan 24, 2018, at 2:07 AM, Miguel Angel Jimenez Achinte <
> > mig...@rigiresearch.com> wrote:
> > >
> > > Hi DJ,
> > >
> > > This is the Zoom link to join the meeting:
> > > https://cloudify.zoom.us/j/5055197842
> > > The meeting currently being scheduled at 11:00AM EST, on Mondays.
> > > That would be 1:00AM in your timezone?
> > >
> > > I leave it to Tom or someone else to discuss about possibly moving 
> > > the meeting to another time.
> > >
> > > Regards,
> > > Miguel
> > >
> > > --
> > > Miguel Jimenez, PhD student
> > > Department of Computer Science
> > > University of Victoria
> > > Engineering/Computer Science Building (ECS), Room 412 Victoria, BC 
> > > V8W 3p6 Canada
> > >
> > > On Tue, Jan 23, 2018 at 10:55 PM, D Jayachandran < 
> > > d.jayachand...@ericsson.com> wrote:
> > >
> > >> Hi Tom,
> > >>
> > >> I would like to attend the grooming meeting in future. My 
> > >> timezone is
> > GST
> > >> + 5:30 .
> > >> What can be the best possible time which you can have the meeting 
> > >> scheduled ?
> > >> Also where can I find the grooming meeting invitation ?
> > >>
> > >> Regards,
> > >> DJ
> > >> -Original Message-
> > >> From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
> > >> Sent: Tuesday, January 23, 2018 1:31 AM
> > >> To: dev@ariatosca.incubator.apache.org
> > >> Subject: Grooming Meeting Minutes: January 22, 2018
> > >>
> > >> Attendees: Tom
> > >>
> > >> Reviewed Jira backlog
> > >>
> > >> Ended early to update release KEYS file and MIT Key server entries.
> > >>
> > >> --Tom
> > >>
> >
> >
>

RE: Grooming Meeting Minutes: January 22, 2018

[D Jayachandran]

Hi,

Even am fine with two meetings. Please let me know the timeslot which can work 
for us.

Regards,
DJ

-Original Message-
From: Miguel Angel Jimenez Achinte [mailto:mig...@rigiresearch.com] 
Sent: Monday, January 29, 2018 9:30 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Grooming Meeting Minutes: January 22, 2018

Hi everyone,
I'm fine with having two grooming meetings. I'd continue joining at 11:00AM EST 
though.
Cheers,
Miguel

On Thu, Jan 25, 2018 at 4:34 AM, Thomas Nadeau <tnadeaua...@gmail.com>
wrote:

>
> Hi guys,
>
> I wanted to discuss the time of the weekly grooming meeting 
> and possibly options for how
> to include everyone - because that is the goal here.   The time currently
> used was chosen because
> it was not too early for people in PST (Miguel) GMT-8 and CST (Tal) as 
> well as to include people in the Israel Time Zone (GMT+2).  This is 
> why 11AM EST (4PM GMT) was chosen - its not too late for people in the 
> eastern zones, and not too early for those in the most western zones.  
> Your time zone is 9 hours ahead of EST if I am not mistaken, which is 
> going to probably be quite difficult to add to the mix, but if others 
> are willing to meet earlier or later, thats fine with me.
>
> I wanted to propose another option: we have two grooming meetings.
> I know that is not ideal,
> but it at least means that everyone can attend one of these.  I can 
> make both because I am sitting in the middle of all of these time 
> zones, so I could keep continuity between meetings.  Of course, we 
> will also ensure that all meeting minutes/decisions are echoed to the 
> list as Apache requires.
>
> When we meet is up to the community here, so please discuss 
> the options I proposed or suggest others so that we might arrive at 
> something we can start with next week.
>
> Cheers,
>
> —Tom
>
>
> > On Jan 24, 2018, at 2:07 AM, Miguel Angel Jimenez Achinte <
> mig...@rigiresearch.com> wrote:
> >
> > Hi DJ,
> >
> > This is the Zoom link to join the meeting:
> > https://cloudify.zoom.us/j/5055197842
> > The meeting currently being scheduled at 11:00AM EST, on Mondays. 
> > That would be 1:00AM in your timezone?
> >
> > I leave it to Tom or someone else to discuss about possibly moving 
> > the meeting to another time.
> >
> > Regards,
> > Miguel
> >
> > --
> > Miguel Jimenez, PhD student
> > Department of Computer Science
> > University of Victoria
> > Engineering/Computer Science Building (ECS), Room 412 Victoria, BC 
> > V8W 3p6 Canada
> >
> > On Tue, Jan 23, 2018 at 10:55 PM, D Jayachandran < 
> > d.jayachand...@ericsson.com> wrote:
> >
> >> Hi Tom,
> >>
> >> I would like to attend the grooming meeting in future. My timezone 
> >> is
> GST
> >> + 5:30 .
> >> What can be the best possible time which you can have the meeting 
> >> scheduled ?
> >> Also where can I find the grooming meeting invitation ?
> >>
> >> Regards,
> >> DJ
> >> -Original Message-
> >> From: Thomas Nadeau [mailto:tnadeaua...@gmail.com]
> >> Sent: Tuesday, January 23, 2018 1:31 AM
> >> To: dev@ariatosca.incubator.apache.org
> >> Subject: Grooming Meeting Minutes: January 22, 2018
> >>
> >> Attendees: Tom
> >>
> >> Reviewed Jira backlog
> >>
> >> Ended early to update release KEYS file and MIT Key server entries.
> >>
> >> --Tom
> >>
>
>

RE: Grooming Meeting Minutes: January 22, 2018

[D Jayachandran]

Hi Tom,

I would like to attend the grooming meeting in future. My timezone is GST + 
5:30 .
What can be the best possible time which you can have the meeting scheduled ?
Also where can I find the grooming meeting invitation ?

Regards,
DJ
-Original Message-
From: Thomas Nadeau [mailto:tnadeaua...@gmail.com] 
Sent: Tuesday, January 23, 2018 1:31 AM
To: dev@ariatosca.incubator.apache.org
Subject: Grooming Meeting Minutes: January 22, 2018

Attendees: Tom

Reviewed Jira backlog

Ended early to update release KEYS file and MIT Key server entries.

--Tom

RE: Node Template Substitution

[D Jayachandran]

Hi Avia,

Can I have some update on the below mail ? We want to contribute for the 
substitution mapping feature with ARIA. 
We have some clarifications with your design notes and is it possible to have a 
meeting scheduled to get our queries clarified ?

Regards,
DJ

-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Wednesday, January 17, 2018 4:04 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Node Template Substitution

Hi Avia,

I had a look at the design notes and I have some questions on the "topology" 
section ?

Topology
After validation the match between the substituted node and the substituting 
template, substitution template is instantiated, and the overall topology is 
created from all the nodes, requirements, and capabilities. If such a topology 
cannot be created, an error is thrown. We are striving to create a unified 
model of both the top level service template and the substituting template, 
without the need from some helper logical nodes that will represent connecting 
points.

I assume the validation happens during the parsing stage when we are creating a 
"service-template" of a top level service template.
Now when you state "substitution template is instantiated", is it the service 
creation from a service-template of a top-level service template ? 

Regards,
DJ

-----Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
Sent: Thursday, January 04, 2018 6:56 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Node Template Substitution

Hi,

Do you have information regarding this ? We are ready to contribute from our 
side.
We need to know the current state and the pending items to be implemented.

Regards,
DJ

-----Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
Sent: Wednesday, December 13, 2017 11:48 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Node Template Substitution

Hi Tal,

Could you point to the open items with respect to substitution mapping, so that 
we can see if we can contribute for those items.

Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co]
Sent: Tuesday, December 12, 2017 7:02 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Node Template Substitution

There is currently no clear timeline. I expect it would take several weeks, 
perhaps months, unless more contributors step up to assist the effort.

On Tue, Dec 12, 2017 at 5:00 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> When can we expect the support for substitution mapping to be merged 
> to master branch ?
>
> Regards,
> DJ
> -Original Message-
> From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com]
> Sent: Friday, December 08, 2017 8:26 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Node Template Substitution
>
> Hi Avia
> I don't access to the design doc. Am I missing something?
>
> Will 0.2.0 support YAML Profile 1.0 or 1.2 topology substitution?
> Or is it postponed to later?
>
> -Steve
>
> -Original Message-
> From: Avia Efrat [mailto:a...@cloudify.co]
> Sent: Tuesday, October 17, 2017 4:44 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Node Template Substitution
>
> There are plans to extend substitution mappings support to TOSCA 1.2, 
> just as any other change/improvement in the 1.2 profile.
>
> A CSAR with one 'main' service template and other service templates 
> will be stored as one service template, and will have one unique name.
>
> The design doc:
> https://drive.google.com/open?id=19nPjSj6mJyXWd4KLxPqRNp_
> TPqLpvXjzj98NXrAmcjc
>
>
> Additional v1.2 issues (a non-exhaustive list):
> https://docs.google.com/document/d/18yZC8qIWMbWBeULOzmLTT_
> oVrZXQ3z4030U6JIXdJ84/edit
>
>
> On Sat, Oct 14, 2017 at 2:10 AM, Steve Baillargeon < 
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi Avia
> > One more question.
> >
> > Say we have a CSAR that contains multiple TOSCA YAML files e.g. a 
> > top-level ST and a bunch of low-level STs.
> > I am assuming all those TOSCA service templates (all of them have a 
> > full topology section) will be stored as a single “service-template”
> > in ARIA and a single unique name is needed to represent such single
> “service-template”
> > composed of multiple topologies.
> > Is this correct?
> >
> > -Steve
> >
> > -Original Message-
> > From: Steve Baillargeon
> > Sent: Wednesday, October 11, 2017 11:29 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: Node Template Substitution
> >
> > Hi Avia
> > Is it possible to review the design documentation for it?
> > Do you have a doc or a few notes describing how AR

RE: Node Template Substitution

[D Jayachandran]

Hi Avia,

I had a look at the design notes and I have some questions on the "topology" 
section ?

Topology
After validation the match between the substituted node and the substituting 
template, substitution template is instantiated, and the overall topology is 
created from all the nodes, requirements, and capabilities. If such a topology 
cannot be created, an error is thrown. We are striving to create a unified 
model of both the top level service template and the substituting template, 
without the need from some helper logical nodes that will represent connecting 
points.

I assume the validation happens during the parsing stage when we are creating a 
"service-template" of a top level service template.
Now when you state "substitution template is instantiated", is it the service 
creation from a service-template of a top-level service template ? 

Regards,
DJ

-----Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Thursday, January 04, 2018 6:56 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Node Template Substitution

Hi,

Do you have information regarding this ? We are ready to contribute from our 
side.
We need to know the current state and the pending items to be implemented.

Regards,
DJ

-----Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
Sent: Wednesday, December 13, 2017 11:48 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Node Template Substitution

Hi Tal,

Could you point to the open items with respect to substitution mapping, so that 
we can see if we can contribute for those items.

Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co]
Sent: Tuesday, December 12, 2017 7:02 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Node Template Substitution

There is currently no clear timeline. I expect it would take several weeks, 
perhaps months, unless more contributors step up to assist the effort.

On Tue, Dec 12, 2017 at 5:00 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> When can we expect the support for substitution mapping to be merged 
> to master branch ?
>
> Regards,
> DJ
> -Original Message-
> From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com]
> Sent: Friday, December 08, 2017 8:26 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Node Template Substitution
>
> Hi Avia
> I don't access to the design doc. Am I missing something?
>
> Will 0.2.0 support YAML Profile 1.0 or 1.2 topology substitution?
> Or is it postponed to later?
>
> -Steve
>
> -Original Message-
> From: Avia Efrat [mailto:a...@cloudify.co]
> Sent: Tuesday, October 17, 2017 4:44 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Node Template Substitution
>
> There are plans to extend substitution mappings support to TOSCA 1.2, 
> just as any other change/improvement in the 1.2 profile.
>
> A CSAR with one 'main' service template and other service templates 
> will be stored as one service template, and will have one unique name.
>
> The design doc:
> https://drive.google.com/open?id=19nPjSj6mJyXWd4KLxPqRNp_
> TPqLpvXjzj98NXrAmcjc
>
>
> Additional v1.2 issues (a non-exhaustive list):
> https://docs.google.com/document/d/18yZC8qIWMbWBeULOzmLTT_
> oVrZXQ3z4030U6JIXdJ84/edit
>
>
> On Sat, Oct 14, 2017 at 2:10 AM, Steve Baillargeon < 
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi Avia
> > One more question.
> >
> > Say we have a CSAR that contains multiple TOSCA YAML files e.g. a 
> > top-level ST and a bunch of low-level STs.
> > I am assuming all those TOSCA service templates (all of them have a 
> > full topology section) will be stored as a single “service-template”
> > in ARIA and a single unique name is needed to represent such single
> “service-template”
> > composed of multiple topologies.
> > Is this correct?
> >
> > -Steve
> >
> > -Original Message-
> > From: Steve Baillargeon
> > Sent: Wednesday, October 11, 2017 11:29 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: Node Template Substitution
> >
> > Hi Avia
> > Is it possible to review the design documentation for it?
> > Do you have a doc or a few notes describing how ARIA will perform 
> > "best matching" based on YAML 1.0/1.1 profile?
> >
> > The full support for NFV Profile 1.0 requires Node Template 
> > Substitution defined in YAML 1.2 profile.
> > Any future plans for ARIA to extend Node Template Substitution as 
> > defined in YAML 1.2 profile ?
> >
> > Regards
> > Steve B
> >
> > -Original Message-
> > From: Arthur Berezin [mailto:art...@clo

RE: Apache and committer account

[D Jayachandran]

It was communicated by Ran Ziv, to submit the ICLA, so I thought I was 
necessary even to contribute.
Now it's clear to me.

-Original Message-
From: Thomas Nadeau [mailto:tnadeaua...@gmail.com] 
Sent: Tuesday, January 09, 2018 5:56 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Apache and committer account

Why are you submitting the ICLA?  You only need to do that after you have been 
voted as a committer by the existing Committers.

--Tom


On Tue, Jan 9, 2018 at 2:00 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi All,
>
> I have already submitted the Apache ICLA and got the below response.
> Please when will the apache account be created for me to be an committer ?
>
> =====
>
> Dear D Jayachandran,
>
>
>
> This message acknowledges receipt of your ICLA, which has been filed 
> in the Apache Software Foundation records.
>
>
>
> With this message, the Incubator PMC and the AriaTosca podling have 
> been notified that your ICLA has been filed.
>
> Please contact them with any questions.
>
>
>
> Warm Regards,
>
>
>
> -- Craig L Russell
>
> Secretary, Apache Software Foundation
> ===
>
> Regards,
> DJ
>

RE: TOSCA spec compliance on finding target node

[D Jayachandran]

Hi Tal,

I have raised a JIRA issue for the below item 
https://issues.apache.org/jira/browse/ARIA-437 
This would be contributed by us.

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, August 07, 2017 9:01 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: TOSCA spec compliance on finding target node

I think you are talking about requirements? Some of the combinations you 
mention are for requirement declarations (at the node type) and some for 
requirement assignments (at the node template).

Generally speaking, ARIA intends to support 100% of the TOSCA spec, so feel 
free to contribute. If a combination does not work, it is a bug.

There is a known bug about requiring a capability without a template that is 
being worked on.

On Mon, Aug 7, 2017 at 12:01 AM, Vaishnavi K.R 
wrote:

> Hi,
>
>
> I tried the following combinations in my service template,
>
>   1.  Type definition with capability type alone but node template 
> having any of the following,
>  *   capability type alone
>  *   capability name alone
>  *   node type alone
>  *   node name alone
>  *   capability name and node name
>  *   capability name and node type
>  *   capability type and node type
>  *   capability type and node type
>   2.  Type definition with capability type and node type
>  *   capability type alone
>  *   capability name alone
>  *   node type alone
>  *   node name alone
>  *   capability name and node name
>  *   capability name and node type
>  *   capability type and node type
>  *   capability type and node type
>
> As per the TOSCA specification, the above are valid combinations.
>
> Will ARIA support all the above ?? If so, we wish to contribute.
>
> Looking forward to your comment.
>
>
>
> Thanks,
>
> /Vaish
>
> 
> From: Tal Liron 
> Sent: Tuesday, July 25, 2017 10:03:18 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: TOSCA spec compliance on finding target node
>
> It indeed should *not* be required. I just verified that it you are 
> correct, and a match is not made if only the capability is specified 
> without a node type/template.
>
> This is a regression, because it used to work correctly.
>
> There is currently work in progress to refactor that mechanism, so I 
> will add a test case to make sure the regression is fixed.
>
> See my test case and follow progress here:
> https://issues.apache.org/jira/browse/ARIA-174
>
> On Tue, Jul 25, 2017 at 3:28 AM, Vaishnavi K.R 
>  >
> wrote:
>
> > Hi ARIA folks,
> >
> >
> > I had a look at the source code of ARIA on how the target node is 
> > identified based on the requirement and capability information 
> > furnished
> in
> > the node template and its corresponding node type. But I find that 
> > only
> few
> > of the combinations are supported i.e., as per the TOSCA spec, in 
> > the requirement section of a node template, the 'node' option is not
> mandatory,
> > but ARIA expects that to be present.
> >
> >
> > In my use-case, my node template has a requirement on a node which 
> > has a particular capability. So I just specify the capability type 
> > in my node template under the requirement section. As ARIA expects 
> > the 'node' option to be present, this use-case fails.
> >
> >
> > So I wish to get clarified is there any specific reason for 
> > mandating the 'node' option or if TOSCA spec compliance on this 
> > target identification based on the capability name or type will be 
> > supported in the future versions?
> >
> >
> > Thanks,
> >
> > /Vaish
> >
>

Apache and committer account

[D Jayachandran]

Hi All,

I have already submitted the Apache ICLA and got the below response.  Please 
when will the apache account be created for me to be an committer ?

=

Dear D Jayachandran,



This message acknowledges receipt of your ICLA, which has been filed in the 
Apache Software Foundation records.



With this message, the Incubator PMC and the AriaTosca podling have been 
notified that your ICLA has been filed.

Please contact them with any questions.



Warm Regards,



-- Craig L Russell

Secretary, Apache Software Foundation
===

Regards,
DJ

RE: Database session management with model storage.

[D Jayachandran]

Thanks Maxim, I will check and contribute accordingly.

Regards,
DJ

From: Maxim Orlov [mailto:ma...@cloudify.co]
Sent: Thursday, January 04, 2018 3:08 PM
To: D Jayachandran <d.jayachand...@ericsson.com>
Cc: dev@ariatosca.incubator.apache.org
Subject: Re: Database session management with model storage.

Well, the question is can we achieve the same functionality via the initiator 
to the model storage. Although it is initiated only once, using the 
sessionfactory with the initiator might help.
If not, it could be a great contribution to the project.

On Wed, Jan 3, 2018 at 7:50 AM D Jayachandran 
<d.jayachand...@ericsson.com<mailto:d.jayachand...@ericsson.com>> wrote:
Hi All,

Currently ARIA functions as a single threaded application particularly with the 
session management. The sql_mapi does not get the session and engine on a 
thread local basis.
We feel it is necessary to make changes in session management to effectively 
support multithreading  scenarios.
If all agree we can contribute on this.

Regards,
DJ
-Original Message-
From: D Jayachandran
Sent: Friday, December 29, 2017 12:01 PM
To: 
dev@ariatosca.incubator.apache.org<mailto:dev@ariatosca.incubator.apache.org>; 
Maxim Orlov <ma...@cloudify.co<mailto:ma...@cloudify.co>>
Subject: RE: Database session management with model storage.

Hi Tal,

More than the database used, I was referring on how the model storage is being 
initialized and exposed.
The sqlalchemy has by its own a sessionfactory and a scopesession to have 
sessions being exposed as thread local.
But With ARIA I feel this is not properly utilized as it is initialized the 
ModelStorage only once.

Please find the below code snippet from env.py where the model storage is 
initialized.
@property
def model_storage(self):
if not self._model_storage:
self._model_storage = self._init_sqlite_model_storage()
return self._model_storage


Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co<mailto:t...@cloudify.co>]
Sent: Friday, December 29, 2017 11:41 AM
To: 
dev@ariatosca.incubator.apache.org<mailto:dev@ariatosca.incubator.apache.org>; 
Maxim Orlov <ma...@cloudify.co<mailto:ma...@cloudify.co>>
Subject: Re: Database session management with model storage.

The default storage, SQLite, has certain concurrency limitations, but if you 
use a more robust server (MySQL, Postresql) there should be no issues.

Maxim, any thoughts?

On Fri, Dec 29, 2017 at 12:01 AM, D Jayachandran < 
d.jayachand...@ericsson.com<mailto:d.jayachand...@ericsson.com>> wrote:

> Hi,
>
> We have built a REST Interface on top of ARIA. With the current
> implementation of ARIA, the "model storage" is seen as a singleton
> class, thereby the database session is also restricted to a single session.
> By exposing ARIA over REST, In a multithreaded scenario we are ending
> up in having the same database session over multiple threads. This
> will bring about issues during various db related actions across multiple 
> requests.
>
> ARIA being a CLI at this moment will not have any issues with this
> approach but to be used and exposed over other interfaces it will be a
> challenge.
> Please let us know if the session management can be handled properly
> with the model storage ? Do you already have any plans to work on this
> item or kindly provide your feedback on this issue.
>
>
> Regards,
> DJ
>

RE: Node Template Substitution

[D Jayachandran]

Hi,

Do you have information regarding this ? We are ready to contribute from our 
side.
We need to know the current state and the pending items to be implemented.

Regards,
DJ

-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Wednesday, December 13, 2017 11:48 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Node Template Substitution

Hi Tal,

Could you point to the open items with respect to substitution mapping, so that 
we can see if we can contribute for those items.

Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co]
Sent: Tuesday, December 12, 2017 7:02 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Node Template Substitution

There is currently no clear timeline. I expect it would take several weeks, 
perhaps months, unless more contributors step up to assist the effort.

On Tue, Dec 12, 2017 at 5:00 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> When can we expect the support for substitution mapping to be merged 
> to master branch ?
>
> Regards,
> DJ
> -Original Message-
> From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com]
> Sent: Friday, December 08, 2017 8:26 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Node Template Substitution
>
> Hi Avia
> I don't access to the design doc. Am I missing something?
>
> Will 0.2.0 support YAML Profile 1.0 or 1.2 topology substitution?
> Or is it postponed to later?
>
> -Steve
>
> -Original Message-
> From: Avia Efrat [mailto:a...@cloudify.co]
> Sent: Tuesday, October 17, 2017 4:44 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Node Template Substitution
>
> There are plans to extend substitution mappings support to TOSCA 1.2, 
> just as any other change/improvement in the 1.2 profile.
>
> A CSAR with one 'main' service template and other service templates 
> will be stored as one service template, and will have one unique name.
>
> The design doc:
> https://drive.google.com/open?id=19nPjSj6mJyXWd4KLxPqRNp_
> TPqLpvXjzj98NXrAmcjc
>
>
> Additional v1.2 issues (a non-exhaustive list):
> https://docs.google.com/document/d/18yZC8qIWMbWBeULOzmLTT_
> oVrZXQ3z4030U6JIXdJ84/edit
>
>
> On Sat, Oct 14, 2017 at 2:10 AM, Steve Baillargeon < 
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi Avia
> > One more question.
> >
> > Say we have a CSAR that contains multiple TOSCA YAML files e.g. a 
> > top-level ST and a bunch of low-level STs.
> > I am assuming all those TOSCA service templates (all of them have a 
> > full topology section) will be stored as a single “service-template”
> > in ARIA and a single unique name is needed to represent such single
> “service-template”
> > composed of multiple topologies.
> > Is this correct?
> >
> > -Steve
> >
> > -Original Message-
> > From: Steve Baillargeon
> > Sent: Wednesday, October 11, 2017 11:29 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: Node Template Substitution
> >
> > Hi Avia
> > Is it possible to review the design documentation for it?
> > Do you have a doc or a few notes describing how ARIA will perform 
> > "best matching" based on YAML 1.0/1.1 profile?
> >
> > The full support for NFV Profile 1.0 requires Node Template 
> > Substitution defined in YAML 1.2 profile.
> > Any future plans for ARIA to extend Node Template Substitution as 
> > defined in YAML 1.2 profile ?
> >
> > Regards
> > Steve B
> >
> > -Original Message-
> > From: Arthur Berezin [mailto:art...@cloudify.co]
> > Sent: Tuesday, October 10, 2017 12:20 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Node Template Substitution
> >
> > Avia, can you please post a link to the design?  thanks
> >
> > On Mon, Oct 9, 2017 at 5:14 PM Avia Efrat <a...@cloudify.co> wrote:
> >
> > > Currently the design is finished, and it is on a small hold for now.
> > > The plan is to support the 1.0/1.1 profile.
> > >
> > > On Wed, Oct 4, 2017 at 7:50 PM, Steve Baillargeon < 
> > > steve.baillarg...@ericsson.com> wrote:
> > >
> > > > Hi
> > > > Can we have a status update on the availability of the Node 
> > > > Template Substitution feature (aka substitution mappings)?
> > > > Will it support the "capabilities" defined in YAML Profile 1.0 
> > > > or YAML Profile 1.2?
> > > >
> > > > Regards
> > > > Steve B
> > > >
> > > >
> > >
> >
>

RE: Database session management with model storage.

[D Jayachandran]

Hi All,

Currently ARIA functions as a single threaded application particularly with the 
session management. The sql_mapi does not get the session and engine on a 
thread local basis.
We feel it is necessary to make changes in session management to effectively 
support multithreading  scenarios. 
If all agree we can contribute on this.

Regards,
DJ 
-Original Message-
From: D Jayachandran 
Sent: Friday, December 29, 2017 12:01 PM
To: dev@ariatosca.incubator.apache.org; Maxim Orlov <ma...@cloudify.co>
Subject: RE: Database session management with model storage.

Hi Tal,

More than the database used, I was referring on how the model storage is being 
initialized and exposed.
The sqlalchemy has by its own a sessionfactory and a scopesession to have 
sessions being exposed as thread local. 
But With ARIA I feel this is not properly utilized as it is initialized the 
ModelStorage only once. 

Please find the below code snippet from env.py where the model storage is 
initialized.
@property
def model_storage(self):
if not self._model_storage:
self._model_storage = self._init_sqlite_model_storage()
return self._model_storage


Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co]
Sent: Friday, December 29, 2017 11:41 AM
To: dev@ariatosca.incubator.apache.org; Maxim Orlov <ma...@cloudify.co>
Subject: Re: Database session management with model storage.

The default storage, SQLite, has certain concurrency limitations, but if you 
use a more robust server (MySQL, Postresql) there should be no issues.

Maxim, any thoughts?

On Fri, Dec 29, 2017 at 12:01 AM, D Jayachandran < d.jayachand...@ericsson.com> 
wrote:

> Hi,
>
> We have built a REST Interface on top of ARIA. With the current 
> implementation of ARIA, the "model storage" is seen as a singleton 
> class, thereby the database session is also restricted to a single session.
> By exposing ARIA over REST, In a multithreaded scenario we are ending 
> up in having the same database session over multiple threads. This 
> will bring about issues during various db related actions across multiple 
> requests.
>
> ARIA being a CLI at this moment will not have any issues with this 
> approach but to be used and exposed over other interfaces it will be a 
> challenge.
> Please let us know if the session management can be handled properly 
> with the model storage ? Do you already have any plans to work on this 
> item or kindly provide your feedback on this issue.
>
>
> Regards,
> DJ
>

RE: Database session management with model storage.

[D Jayachandran]

Hi Tal,

More than the database used, I was referring on how the model storage is being 
initialized and exposed.
The sqlalchemy has by its own a sessionfactory and a scopesession to have 
sessions being exposed as thread local. 
But With ARIA I feel this is not properly utilized as it is initialized the 
ModelStorage only once. 

Please find the below code snippet from env.py where the model storage is 
initialized.
@property
def model_storage(self):
if not self._model_storage:
self._model_storage = self._init_sqlite_model_storage()
return self._model_storage


Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Friday, December 29, 2017 11:41 AM
To: dev@ariatosca.incubator.apache.org; Maxim Orlov <ma...@cloudify.co>
Subject: Re: Database session management with model storage.

The default storage, SQLite, has certain concurrency limitations, but if you 
use a more robust server (MySQL, Postresql) there should be no issues.

Maxim, any thoughts?

On Fri, Dec 29, 2017 at 12:01 AM, D Jayachandran < d.jayachand...@ericsson.com> 
wrote:

> Hi,
>
> We have built a REST Interface on top of ARIA. With the current 
> implementation of ARIA, the "model storage" is seen as a singleton 
> class, thereby the database session is also restricted to a single session.
> By exposing ARIA over REST, In a multithreaded scenario we are ending 
> up in having the same database session over multiple threads. This 
> will bring about issues during various db related actions across multiple 
> requests.
>
> ARIA being a CLI at this moment will not have any issues with this 
> approach but to be used and exposed over other interfaces it will be a 
> challenge.
> Please let us know if the session management can be handled properly 
> with the model storage ? Do you already have any plans to work on this 
> item or kindly provide your feedback on this issue.
>
>
> Regards,
> DJ
>

Database session management with model storage.

[D Jayachandran]

Hi,

We have built a REST Interface on top of ARIA. With the current implementation 
of ARIA, the "model storage" is seen as a singleton class, thereby the database 
session is also restricted to a single session.
By exposing ARIA over REST, In a multithreaded scenario we are ending up in 
having the same database session over multiple threads. This will bring about 
issues during various db related actions across multiple requests.

ARIA being a CLI at this moment will not have any issues with this approach but 
to be used and exposed over other interfaces it will be a challenge.
Please let us know if the session management can be handled properly with the 
model storage ? Do you already have any plans to work on this item or kindly 
provide your feedback on this issue.


Regards,
DJ

RE: meeting minutes Monday, December 18, 2017

[D Jayachandran]

Hi Thomas,

I would also try to join the meeting henceforth, but what is the timezone you 
usually call for ?

Am in GST + 5:30 timezone

Regards,
DJ
-Original Message-
From: Thomas Nadeau [mailto:tnadeaua...@gmail.com] 
Sent: Monday, December 18, 2017 9:42 PM
To: dev@ariatosca.incubator.apache.org
Subject: meeting minutes Monday, December 18, 2017

Attendees: Tom

No one else showed up today, so I ended the meeting at 10 after. If anyone 
would like to discuss the backlog this week, send a note here to the list to 
discuss.

Cheers,

--Tom

RE: Node Template Substitution

[D Jayachandran]

Hi Tal,

Could you point to the open items with respect to substitution mapping, so that 
we can see if we can contribute for those items.

Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Tuesday, December 12, 2017 7:02 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Node Template Substitution

There is currently no clear timeline. I expect it would take several weeks, 
perhaps months, unless more contributors step up to assist the effort.

On Tue, Dec 12, 2017 at 5:00 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> When can we expect the support for substitution mapping to be merged 
> to master branch ?
>
> Regards,
> DJ
> -Original Message-
> From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com]
> Sent: Friday, December 08, 2017 8:26 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Node Template Substitution
>
> Hi Avia
> I don't access to the design doc. Am I missing something?
>
> Will 0.2.0 support YAML Profile 1.0 or 1.2 topology substitution?
> Or is it postponed to later?
>
> -Steve
>
> -Original Message-
> From: Avia Efrat [mailto:a...@cloudify.co]
> Sent: Tuesday, October 17, 2017 4:44 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Node Template Substitution
>
> There are plans to extend substitution mappings support to TOSCA 1.2, 
> just as any other change/improvement in the 1.2 profile.
>
> A CSAR with one 'main' service template and other service templates 
> will be stored as one service template, and will have one unique name.
>
> The design doc:
> https://drive.google.com/open?id=19nPjSj6mJyXWd4KLxPqRNp_
> TPqLpvXjzj98NXrAmcjc
>
>
> Additional v1.2 issues (a non-exhaustive list):
> https://docs.google.com/document/d/18yZC8qIWMbWBeULOzmLTT_
> oVrZXQ3z4030U6JIXdJ84/edit
>
>
> On Sat, Oct 14, 2017 at 2:10 AM, Steve Baillargeon < 
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi Avia
> > One more question.
> >
> > Say we have a CSAR that contains multiple TOSCA YAML files e.g. a 
> > top-level ST and a bunch of low-level STs.
> > I am assuming all those TOSCA service templates (all of them have a 
> > full topology section) will be stored as a single “service-template”
> > in ARIA and a single unique name is needed to represent such single
> “service-template”
> > composed of multiple topologies.
> > Is this correct?
> >
> > -Steve
> >
> > -Original Message-
> > From: Steve Baillargeon
> > Sent: Wednesday, October 11, 2017 11:29 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: Node Template Substitution
> >
> > Hi Avia
> > Is it possible to review the design documentation for it?
> > Do you have a doc or a few notes describing how ARIA will perform 
> > "best matching" based on YAML 1.0/1.1 profile?
> >
> > The full support for NFV Profile 1.0 requires Node Template 
> > Substitution defined in YAML 1.2 profile.
> > Any future plans for ARIA to extend Node Template Substitution as 
> > defined in YAML 1.2 profile ?
> >
> > Regards
> > Steve B
> >
> > -Original Message-
> > From: Arthur Berezin [mailto:art...@cloudify.co]
> > Sent: Tuesday, October 10, 2017 12:20 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Node Template Substitution
> >
> > Avia, can you please post a link to the design?  thanks
> >
> > On Mon, Oct 9, 2017 at 5:14 PM Avia Efrat <a...@cloudify.co> wrote:
> >
> > > Currently the design is finished, and it is on a small hold for now.
> > > The plan is to support the 1.0/1.1 profile.
> > >
> > > On Wed, Oct 4, 2017 at 7:50 PM, Steve Baillargeon < 
> > > steve.baillarg...@ericsson.com> wrote:
> > >
> > > > Hi
> > > > Can we have a status update on the availability of the Node 
> > > > Template Substitution feature (aka substitution mappings)?
> > > > Will it support the "capabilities" defined in YAML Profile 1.0 
> > > > or YAML Profile 1.2?
> > > >
> > > > Regards
> > > > Steve B
> > > >
> > > >
> > >
> >
>

RE: Node Template Substitution

[D Jayachandran]

Hi,

When can we expect the support for substitution mapping to be merged to master 
branch ?

Regards,
DJ
-Original Message-
From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com] 
Sent: Friday, December 08, 2017 8:26 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Node Template Substitution

Hi Avia
I don't access to the design doc. Am I missing something?

Will 0.2.0 support YAML Profile 1.0 or 1.2 topology substitution?
Or is it postponed to later?

-Steve

-Original Message-
From: Avia Efrat [mailto:a...@cloudify.co]
Sent: Tuesday, October 17, 2017 4:44 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Node Template Substitution

There are plans to extend substitution mappings support to TOSCA 1.2, just as 
any other change/improvement in the 1.2 profile.

A CSAR with one 'main' service template and other service templates will be 
stored as one service template, and will have one unique name.

The design doc:
https://drive.google.com/open?id=19nPjSj6mJyXWd4KLxPqRNp_TPqLpvXjzj98NXrAmcjc


Additional v1.2 issues (a non-exhaustive list):
https://docs.google.com/document/d/18yZC8qIWMbWBeULOzmLTT_oVrZXQ3z4030U6JIXdJ84/edit


On Sat, Oct 14, 2017 at 2:10 AM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Hi Avia
> One more question.
>
> Say we have a CSAR that contains multiple TOSCA YAML files e.g. a 
> top-level ST and a bunch of low-level STs.
> I am assuming all those TOSCA service templates (all of them have a 
> full topology section) will be stored as a single “service-template”
> in ARIA and a single unique name is needed to represent such single 
> “service-template”
> composed of multiple topologies.
> Is this correct?
>
> -Steve
>
> -Original Message-
> From: Steve Baillargeon
> Sent: Wednesday, October 11, 2017 11:29 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Node Template Substitution
>
> Hi Avia
> Is it possible to review the design documentation for it?
> Do you have a doc or a few notes describing how ARIA will perform 
> "best matching" based on YAML 1.0/1.1 profile?
>
> The full support for NFV Profile 1.0 requires Node Template 
> Substitution defined in YAML 1.2 profile.
> Any future plans for ARIA to extend Node Template Substitution as 
> defined in YAML 1.2 profile ?
>
> Regards
> Steve B
>
> -Original Message-
> From: Arthur Berezin [mailto:art...@cloudify.co]
> Sent: Tuesday, October 10, 2017 12:20 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Node Template Substitution
>
> Avia, can you please post a link to the design?  thanks
>
> On Mon, Oct 9, 2017 at 5:14 PM Avia Efrat  wrote:
>
> > Currently the design is finished, and it is on a small hold for now.
> > The plan is to support the 1.0/1.1 profile.
> >
> > On Wed, Oct 4, 2017 at 7:50 PM, Steve Baillargeon < 
> > steve.baillarg...@ericsson.com> wrote:
> >
> > > Hi
> > > Can we have a status update on the availability of the Node 
> > > Template Substitution feature (aka substitution mappings)?
> > > Will it support the "capabilities" defined in YAML Profile 1.0 or 
> > > YAML Profile 1.2?
> > >
> > > Regards
> > > Steve B
> > >
> > >
> >
>

RE: Free PyCharm license for ARIA work?

[D Jayachandran]

Hi Tal,

Am still facing the issue even after a "make clean" and from a fresh clone. Am 
facing this error only when running the execution in debug mode.
The error is thrown by the pydev plugin, check below for the stack trace. 
Please let me know if you have any clue on this.


warning: Debugger speedups using cython not found. Run 
'"/proj/tosca-o/common/dev_tools/python/bin/python" 
"/proj/tosca-o/common/dev_tools/eclipse_neon_4.6/plugins/org.python.pydev_6.0.0.201709191431/pysrc/setup_cython.py"
 build_ext --inplace' to build.
pydev debugger: starting (pid: 86306)
Starting execution. Press Ctrl+C cancel
Starting 'install' workflow execution
warning: Debugger speedups using cython not found. Run 
'"/proj/tosca-o/common/dev_tools/python/bin/python" 
"/proj/tosca-o/common/dev_tools/eclipse_neon_4.6/plugins/org.python.pydev_6.0.0.201709191431/pysrc/setup_cython.py"
 build_ext --inplace' to build.
pydev debugger: starting (pid: 86343)
Traceback (most recent call last):
  File 
"/proj/tosca-o/common/dev_tools/eclipse_neon_4.6/plugins/org.python.pydev_6.0.0.201709191431/pysrc/pydevd.py",
 line 1621, in 
main()
  File 
"/proj/tosca-o/common/dev_tools/eclipse_neon_4.6/plugins/org.python.pydev_6.0.0.201709191431/pysrc/pydevd.py",
 line 1615, in main
globals = debugger.run(setup['file'], None, None, is_module)
  File 
"/proj/tosca-o/common/dev_tools/eclipse_neon_4.6/plugins/org.python.pydev_6.0.0.201709191431/pysrc/pydevd.py",
 line 1022, in run
pydev_imports.execfile(file, globals, locals)  # execute the script
  File 
"/workarea/tosca-o/evyzzae/incubator-ariatosca/aria/orchestrator/workflows/executor/process.pyc",
 line 1
SyntaxError: Non-ASCII character '\xf3' in file 
/workarea/tosca-o/evyzzae/incubator-ariatosca/aria/orchestrator/workflows/executor/process.pyc
 on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ 
for details

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Friday, October 13, 2017 10:05 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Free PyCharm license for ARIA work?

Hm, I don't see any non-ASCII character in the source code. Perhaps try to 
delete all your *.pyc files so that they get regenerated. You can run "make 
clean" in the root directory to do that.

On Fri, Oct 13, 2017 at 3:55 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Tal,
>
> Am facing an issue with PyDev when I trigger an execution in debug mode.
>
> SyntaxError: Non-ASCII character '\xf3' in file 
> /home/evyzzae/tosca-repo/ 
> apache-aria/aria/orchestrator/workflows/executor/process.pyc on line 
> 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ 
> for details
>
> Are you aware of this ?
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, October 12, 2017 12:05 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Free PyCharm license for ARIA work?
>
> I just want to point out that I do all my development with the free 
> PyDev IDE (based on Eclipse) and am very satisfied with it.
>
> On Wed, Oct 11, 2017 at 1:21 PM, Thomas Nadeau 
> <tnad...@lucidvision.com>
> wrote:
>
> >
> > Cool. Thanks. It looks like there is a special deal for 
> > Apache
> > projects:
> >
> > You should have @apache.org email to apply Your order will be 
> > processed automatically after the application is submitted
> >
> > The catch-22 is that Vish is not a committer (i.e.: he does 
> > not have an apache.org email), so we might be SOL here.
> >
> > —Tom
> >
> >
> >
> > > On Oct 11, 2017, at 2:17 PM, Jakob Homan <jgho...@gmail.com> wrote:
> > >
> > > JetBrains kindly provides open source licenses for sustained
> > > contributors: https://www.jetbrains.com/buy/opensource/  They have 
> > > a separate set of Apache requirements.  This is a consideration 
> > > they provide, not something that ASF does.
> > >
> > > -Jakob
> > >
> > > On 11 October 2017 at 11:01, Vishwanath Jayaraman 
> > > <vishwana...@hotmail.com> wrote:
> > >> Was curious if there is a free PyCharm license that Apache 
> > >> provides for
> > contributors that contribute to the ARIA project?
> > >>
> > >> When I was contributing to the OpenStack Tacker and Neutron 
> > >> projects, I
> > was able to request such a free license, hence the above question.
> > >>
> > >>
> > >> Vish
> >
> >
>

RE: ARIA-118 plugin.yaml importing

[D Jayachandran]

Hi Tal,

Do you have any comments for this PR ? And can you also share your comments for 
my proposal to handle global TOSCA type definitions.

Regards,
DJ
-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Thursday, December 07, 2017 11:50 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: ARIA-118 plugin.yaml importing

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 <tnadeaua...@gmail.com> 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 
> > <d.jayachand...@ericsson.com>
> > 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: 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 <tnadeaua...@gmail.com> 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 
> > <d.jayachand...@ericsson.com>
> > 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: ARIA-118 plugin.yaml importing

[D Jayachandran]

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 <d.jayachand...@ericsson.com>
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

ARIA-118 plugin.yaml importing

[D Jayachandran]

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: pip executable expected as part of plugin install.

[D Jayachandran]

Hi Ran,

Sorry I had missed to answer this thread. Just to answer your question wagon 
also expects pip as a binary "/usr/bin/pip".  The above path may not be the 
same for al distros of linux and when the path varies we run into the issue/
As I already told we could probably fix this issue by using pip as library 
instead of a 3PP. 
Please let me know if we can also apply the same fix with wagon as well.

Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co] 
Sent: Sunday, August 20, 2017 12:40 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: pip executable expected as part of plugin install.

Can you try to explain again what's the issue you're seeing with the way Wagon 
works right now?
We could create a pull request for Wagon as well, but I'm not sure I understand 
the problem at the moment.

On Wed, Aug 16, 2017 at 6:04 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Even if we fix the issue in ARIA. Wagon library still uses the same 
> logic in finding the pip path and it is wrong.
> Am not sure how to fix this with wagon.
>
> Regards,
> DJ
> -Original Message-
> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> Sent: Thursday, August 03, 2017 5:00 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: pip executable expected as part of plugin install.
>
> Thanks Avia, I will open an issue.
>
> Regards,
> DJ
>
> -Original Message-
> From: Avia Efrat [mailto:a...@cloudify.co]
> Sent: Thursday, August 03, 2017 4:01 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: pip executable expected as part of plugin install.
>
> Hi DJ,
> It seems you are correct, I don't see a reason for not using the pip 
> library.
> Maybe it was that way since we didn't want to add pip as a dependency 
> explicitly (this code is from the beginning of ARIA).
>
> Feel free to open an issue about that =)
>
> On Wed, Aug 2, 2017 at 10:19 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > Am using a Ubuntu version of linux for my development and ARIA does 
> > not find the correct path of pip during the plugin install.
> > To be precise this happens when pip freeze is executed.
> >
> > @staticmethod
> > def _pip_freeze():
> > """Run pip freeze in current environment and return the output"""
> > bin_dir = 'Scripts' if os.name == 'nt' else 'bin'
> > pip_path = os.path.join(sys.prefix, bin_dir,
> > 'pip{0}'.format('.exe' if os.name ==
> 'nt'
> > else ''))
> > pip_freeze = subprocess.Popen([pip_path, 'freeze'],
> > stdout=subprocess.PIPE)
> > pip_freeze_output, _ = pip_freeze.communicate()
> > assert not pip_freeze.poll()
> > return pip_freeze_output
> >
> > Now the question is why are we executing a pip command directly and 
> > not using pip as a library.
> >
> >
> > Regards,
> > DJ
> >
>

RE: Support for extension point during service execution

[D Jayachandran]

Hi Tal,

For our use case we have already built a REST Layer on top of ARIA for 
service-template, services and execution creation/start.
Now for this particular use-case we were looking if we could take the service 
model object and create a service context object out of it, to be provided to 
the service level plugin.
I was thinking if we had to do this, can this be included as part of ARIA 
(Atleast creation of service context object)

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Wednesday, November 29, 2017 1:46 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Support for extension point during service execution

We half do. :) Actually, this has become a major topic of discussion recently 
on other lists. There's some room to discuss exactly what and how is available 
to the ctx proxy. Right now it's both too unrestricted and too narrow. The 
current idea is to make the exposure more explicit, and possibly align it with 
a more general REST API.

On Wed, Nov 29, 2017 at 12:34 AM, D Jayachandran < d.jayachand...@ericsson.com> 
wrote:

> Hi Tal,
>
> I agree with your points mentioned below but I was thinking do we need 
> to have a ServiceLevel operation context, as we now have Node 
> operation context.
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Friday, November 24, 2017 10:12 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Support for extension point during service execution
>
> Hi DJ,
>
> The question here is why use ARIA's orchestrator at all? It sounds 
> like you have your own orchestration engine. This is an intended use 
> case for ARIA (and indeed was used in the OPEN-O project).
>
> There are a few ways to use ARIA here:
>
> 1) You can use the ARIA's Python API and access all the data models 
> directly. Of course this will only work if your own orchestration code 
> is in Python.
> 2) You can use ARIA's CLI to emit the data models you need in either 
> JSON or YAML format, for easy consumption by your code: aria services 
> show myservice --json. Note that you can also wrap ARIA's CLI in an HTTP 
> service.
> 3) You can access the database directly. ARIA uses a a normalized 
> relational (SQL) database.
>
> There are some challenges and limitations to each approach. If you 
> tell us what you're going to do we can help you move along in that direction.
>
>
> On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Team,
> >
> > We are looking at an execution point during a service execution 
> > through a plugin. With this the execution will not go through the 
> > workflow runner
> > (install/uninstall) defined by the orchestrator but the services 
> > instance context object will be provided to the plugin which will 
> > take care of the complete service-execution.
> > This plugin is looked upon as a "service plugin" which will get the 
> > entire service model object and will provide the details to the 
> > external workflow engine.
> > We need this feature to enable the execution of workflows which some 
> > of our users already have. Please let us know your thoughts on this 
> > as we have already started our technical study on this.
> >
> >
> > Regards,
> > DJ
> >
>

RE: Support for extension point during service execution

[D Jayachandran]

Hi Tal,

I agree with your points mentioned below but I was thinking do we need to have 
a ServiceLevel operation context, as we now have Node operation context.

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Friday, November 24, 2017 10:12 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Support for extension point during service execution

Hi DJ,

The question here is why use ARIA's orchestrator at all? It sounds like you 
have your own orchestration engine. This is an intended use case for ARIA (and 
indeed was used in the OPEN-O project).

There are a few ways to use ARIA here:

1) You can use the ARIA's Python API and access all the data models directly. 
Of course this will only work if your own orchestration code is in Python.
2) You can use ARIA's CLI to emit the data models you need in either JSON or 
YAML format, for easy consumption by your code: aria services show myservice 
--json. Note that you can also wrap ARIA's CLI in an HTTP service.
3) You can access the database directly. ARIA uses a a normalized relational 
(SQL) database.

There are some challenges and limitations to each approach. If you tell us what 
you're going to do we can help you move along in that direction.


On Fri, Nov 24, 2017 at 7:37 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Team,
>
> We are looking at an execution point during a service execution 
> through a plugin. With this the execution will not go through the 
> workflow runner
> (install/uninstall) defined by the orchestrator but the services 
> instance context object will be provided to the plugin which will take 
> care of the complete service-execution.
> This plugin is looked upon as a "service plugin" which will get the 
> entire service model object and will provide the details to the 
> external workflow engine.
> We need this feature to enable the execution of workflows which some 
> of our users already have. Please let us know your thoughts on this as 
> we have already started our technical study on this.
>
>
> Regards,
> DJ
>

Support for extension point during service execution

[D Jayachandran]

Hi Team,

We are looking at an execution point during a service execution through a 
plugin. With this the execution will not go through the workflow runner 
(install/uninstall) defined by the orchestrator but the services instance 
context object will be provided to the plugin which will take care of the 
complete service-execution.
This plugin is looked upon as a "service plugin" which will get the entire 
service model object and will provide the details to the external workflow 
engine.
We need this feature to enable the execution of workflows which some of our 
users already have. Please let us know your thoughts on this as we have already 
started our technical study on this.


Regards,
DJ

RE: Implementation for get_operation_output

[D Jayachandran]

Hi Tal,

Will the below work at this moment ?

ctx return my_value = this is the value
And then you could use get_operation_output on "my_value".


Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Thursday, November 09, 2017 10:14 PM
To: dev@ariatosca.incubator.apache.org
Cc: Paul Doyle <paul.do...@ericsson.com>; Barry Downey 
<barry.dow...@ericsson.com>
Subject: Re: Implementation for get_operation_output

This function has not yet been implemented, so it's stored nowhere. But of 
course it will likely have to be stored per particular execution.

The "ctx" tool is just a way to remotely access the context object, so yes, 
with plugins it's identical.

On Thu, Nov 9, 2017 at 1:14 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Tal,
>
> To understand a bit more, so where are these return values stored ? 
> Would they updated to services as we do with TOSCA attributes or do 
> they live only for a particular execution ?
> Also when it comes to plugin, can I do the same with the context 
> object being passed rather than using the "ctx" tool ?
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, November 08, 2017 8:06 PM
> To: dev@ariatosca.incubator.apache.org
> Cc: Paul Doyle <paul.do...@ericsson.com>; Barry Downey < 
> barry.dow...@ericsson.com>
> Subject: Re: Implementation for get_operation_output
>
> ARIA currently uses a special tool, called "ctx", to communicate with 
> implementation scripts. I imagine we will use the same tool to set 
> return values.
>
> My understanding is also that these return values are quite arbitrary, 
> and thus un-typed. They will likely be stored as strings. So, for 
> example, from within a bash script you would do something like this:
>
> ctx return my_value = this is the value
>
> And then you could use get_operation_output on "my_value".
>
>
> On Tue, Nov 7, 2017 at 5:55 AM, D Jayachandran < 
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi All,
> >
> > We currently don't have an implementation for the intrinsic function 
> > "get_operation_output".
> >
> > As per the TOSCA Simple YAML 1.0, specification it indicates this 
> > function must be used to retrieve the values of variables exposed / 
> > exported from an interface operation.
> > The variable which is referenced here seems to be an environmental 
> > variable exposed by the interface operation script/plugin. (2.14.3
> Example:
> > setting output variables to an attribute, 2.14.4 Example: passing 
> > output variables between operations )
> >
> > We would like if you have the same understanding on the variable 
> > which is referenced in "get_operation_output".
> >
> > FROM TOSCA SPEC
> >
> >  - The required name of the variable that is 
> > exposed / exported by the operation.
> >
> > Here it is just stated as a variable. In the example it is mentioned 
> > as "environmental" variable exposed. Do you see a difference here ?
> > Are we considering as an environmental variable or as an attribute
> variable ?.
> >
> > Please let us know your comments on this so that we can plan the 
> > implementation of this.
> >
> > Regards,
> > DJ
> >
>

RE: Implementation for get_operation_output

[D Jayachandran]

Hi Tal,

To understand a bit more, so where are these return values stored ? Would they 
updated to services as we do with TOSCA attributes or do they live only for a 
particular execution ?
Also when it comes to plugin, can I do the same with the context object being 
passed rather than using the "ctx" tool ?

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Wednesday, November 08, 2017 8:06 PM
To: dev@ariatosca.incubator.apache.org
Cc: Paul Doyle <paul.do...@ericsson.com>; Barry Downey 
<barry.dow...@ericsson.com>
Subject: Re: Implementation for get_operation_output

ARIA currently uses a special tool, called "ctx", to communicate with 
implementation scripts. I imagine we will use the same tool to set return 
values.

My understanding is also that these return values are quite arbitrary, and thus 
un-typed. They will likely be stored as strings. So, for example, from within a 
bash script you would do something like this:

ctx return my_value = this is the value

And then you could use get_operation_output on "my_value".


On Tue, Nov 7, 2017 at 5:55 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi All,
>
> We currently don't have an implementation for the intrinsic function 
> "get_operation_output".
>
> As per the TOSCA Simple YAML 1.0, specification it indicates this 
> function must be used to retrieve the values of variables exposed / 
> exported from an interface operation.
> The variable which is referenced here seems to be an environmental 
> variable exposed by the interface operation script/plugin. (2.14.3 Example:
> setting output variables to an attribute, 2.14.4 Example: passing 
> output variables between operations )
>
> We would like if you have the same understanding on the variable which 
> is referenced in "get_operation_output".
>
> FROM TOSCA SPEC
>
>  - The required name of the variable that is 
> exposed / exported by the operation.
>
> Here it is just stated as a variable. In the example it is mentioned 
> as "environmental" variable exposed. Do you see a difference here ? 
> Are we considering as an environmental variable or as an attribute variable ?.
>
> Please let us know your comments on this so that we can plan the 
> implementation of this.
>
> Regards,
> DJ
>

Implementation for get_operation_output

[D Jayachandran]

Hi All,

We currently don't have an implementation for the intrinsic function 
"get_operation_output".

As per the TOSCA Simple YAML 1.0, specification it indicates this function must 
be used to retrieve the values of variables exposed / exported from an 
interface operation.
The variable which is referenced here seems to be an environmental variable 
exposed by the interface operation script/plugin. (2.14.3 Example: setting 
output variables to an attribute, 2.14.4 Example: passing output variables 
between operations )

We would like if you have the same understanding on the variable which is 
referenced in "get_operation_output".

FROM TOSCA SPEC

 - The required name of the variable that is exposed / 
exported by the operation.

Here it is just stated as a variable. In the example it is mentioned as 
"environmental" variable exposed. Do you see a difference here ? Are we 
considering as an environmental variable or as an attribute variable ?.

Please let us know your comments on this so that we can plan the implementation 
of this.

Regards,
DJ

RE: Contribution for https://issues.apache.org/jira/browse/ARIA-118

[D Jayachandran]

Hi Tal,

We have started to work on the plugin import part. Just to re-confirm we would 
going with the below convention and contributing it back to ARIA. Please let me 
know if you have any comments.

imports:
- file: -
  repository: plugins
- file: -
  repository: plugins

Example:

imports:
- file: openstack-1.0
  repository: plugins
- file: kubernetes-1.0
  repository: plugins

NOTE: We are not looking at having the extension ".yaml" mandated.

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Tuesday, September 26, 2017 11:56 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118

That's how ARIA implements it right now. I consider the TOSCA 1.0 spec on 
"imports" to be an error because it contradicts the rest of the document, so we 
have always used the correction as it now appears in 1.2. This is not the only 
place where we had to resolve contradictions, by any means. :)

I'm getting very close to finishing work the complete parser test suite, so it 
will give us a good centralized place to check and confirm grammar.

By the way, take care to mention TOSCA specifically when you refer to versions. 
"YAML 1.1" refers to the YAML spec. (We actually use YAML 1.2.)


On Tue, Sep 26, 2017 at 1:06 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Tal,
>
> Are we looking at the below syntax for plugins, with the changes in 
> YAML
> 1.1
>
> Imports:
> - file: openstack-1.0
>   repository: plugins
> - file: kubernetes-1.0
>   repository: plugins
>
> Regards,
> DJ
> -Original Message-
> From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com]
> Sent: Monday, September 25, 2017 11:24 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Contribution for https://issues.apache.org/
> jira/browse/ARIA-118
>
> Hi
> YAML1.0 spec is incorrect for import definitions.
> YAML1.2 spec has updated the import grammar as follows.
> It will be great for ARIA to support parts of the YAML1.2 spec soon 
> especially for areas that are corrected.
>
> From YAML 1.2 spec:
> 3.5.8.2 Grammar
> Import definitions have one the following grammars:
> 3.5.8.2.1 Single-line grammar:
> imports:
>   - 
>   - 
> 3.5.8.2.2 Multi-line grammar
> imports:
>   - file: 
> repository: 
> namespace_uri: 
> namespace_prefix: 
>
> -Steve B
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Monday, September 25, 2017 11:39 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Contribution for https://issues.apache.org/
> jira/browse/ARIA-118
>
> So, this is one of the cases where the spec seems to be wrong: the 
>  is probably a mistake. None of the other examples in the 
> spec have it, nor do we see it in other TOSCA examples.
>
> Note that if we needed an  than it would even have to be 
> for the short form. So:
>
> imports:
>  - importname1: myfile.yaml
>  - importname2: otherfile.yaml
>  - importname3:
>      file: lastfile.yaml
>
> The above seems wrong (also, what role does the import name have?). In 
> ARIA we treated this as an error in the spec, so we do not have the 
> import name.
>
> On Mon, Sep 25, 2017 at 8:52 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Tal,
> >
> > As per the grammer in the SPEC, seems the import should take a 
> > . Your example dint have a  but started 
> > with respository as such.
> >
> > :
> >
> >   file: 
> >
> >   repository: 
> >
> >   namespace_uri: 
> >
> >   namespace_prefix: 
> >
> >
> > With your example can we have multiple repositories ?
> >
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Thursday, September 21, 2017 9:31 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Contribution for https://issues.apache.org/
> > jira/browse/ARIA-118
> >
> > I do suggest the repository, because it seems like the more TOSCA 
> > way to do this. These are special imports that are not part of the 
> > CSAR but rather provided in a special way by ARIA. A special 
> > repository seems to be the right way to handle this.
> >
> > On Thu, Sep 21, 2017 at 2:40 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi Tal,
> > >
> > > I had a space between the plugin and filename. The correct one 
> >

RE: Free PyCharm license for ARIA work?

[D Jayachandran]

Hi Tal,

Am facing an issue with PyDev when I trigger an execution in debug mode.

SyntaxError: Non-ASCII character '\xf3' in file 
/home/evyzzae/tosca-repo/apache-aria/aria/orchestrator/workflows/executor/process.pyc
 on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ 
for details

Are you aware of this ?


Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Thursday, October 12, 2017 12:05 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Free PyCharm license for ARIA work?

I just want to point out that I do all my development with the free PyDev IDE 
(based on Eclipse) and am very satisfied with it.

On Wed, Oct 11, 2017 at 1:21 PM, Thomas Nadeau 
wrote:

>
> Cool. Thanks. It looks like there is a special deal for Apache
> projects:
>
> You should have @apache.org email to apply Your order will be 
> processed automatically after the application is submitted
>
> The catch-22 is that Vish is not a committer (i.e.: he does 
> not have an apache.org email), so we might be SOL here.
>
> —Tom
>
>
>
> > On Oct 11, 2017, at 2:17 PM, Jakob Homan  wrote:
> >
> > JetBrains kindly provides open source licenses for sustained
> > contributors: https://www.jetbrains.com/buy/opensource/  They have a 
> > separate set of Apache requirements.  This is a consideration they 
> > provide, not something that ASF does.
> >
> > -Jakob
> >
> > On 11 October 2017 at 11:01, Vishwanath Jayaraman 
> >  wrote:
> >> Was curious if there is a free PyCharm license that Apache provides 
> >> for
> contributors that contribute to the ARIA project?
> >>
> >> When I was contributing to the OpenStack Tacker and Neutron 
> >> projects, I
> was able to request such a free license, hence the above question.
> >>
> >>
> >> Vish
>
>

RE: Openstack plugin

[D Jayachandran]

Hi,

The cloudify openstack plugin has validation interfaces, Do they still hold 
good with ARIA with the use of adapter ?


Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co] 
Sent: Tuesday, August 08, 2017 5:33 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Openstack plugin

For future readers of this thread, you can find an example on how to use this 
plugin here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/OpenStack+Hello+World

On Wed, Jul 26, 2017 at 6:25 PM, Maxim Orlov <ma...@cloudify.co> wrote:

> you got most of it right :). You would need to follow these steps:
> 1. Install the adapter
> 2. Using ARIA, Install the wagon of the plugin.
> 3. Utilize the corresponding plugin.yaml found in the repo in your 
> templates.
>
> The reason the adapter does not come with ARIA is it's an adapter for 
> Cloudify based plugins, and hence it cannot be a part of the ARIA code 
> base.
> In the future ARIA would have its own plugins, and will not need the 
> adapter for Cloudify plugins.
>
> On Wed, Jul 26, 2017 at 12:20 PM, D Jayachandran < 
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Max,
> >
> > IF I understand correctly,
> > we need to take the cloudify openstack plugin and replace 
> > the plugin.yaml with the one found in the repo.
> > Install this updated plugin with ARIA
> > Install the adapter found in this repo to make use of the 
> > plugin
> >
> > Am I right with my understanding ?  Also why this adapter is not 
> > included with ARIA by default ?
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Maxim Orlov [mailto:ma...@gigaspaces.com]
> > Sent: Monday, July 24, 2017 9:17 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Openstack plugin
> >
> > Hey DJ,
> >
> > Basically ARIA indeed has an adapter for cloudify-based plugins. 
> > This enables support for any cloudify plugins (Provided the 
> > plugin.yaml has
> been
> > translated into TOSCA). Note that later on, ARIA will have native 
> > plugins and will not rely on kindness of Cloudify.
> > You can find the Cloudify repo here
> > <https://github.com/cloudify-cosmo/aria-extension-cloudify>. It 
> > holds some examples, the plugin.yaml and the adapter itself.
> >
> > On Mon, Jul 24, 2017 at 2:01 PM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Thanks for the information Tal.  What is the adapter which you are 
> > > referring here ?
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@gigaspaces.com]
> > > Sent: Friday, July 21, 2017 8:37 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Openstack plugin
> > >
> > > ARIA has an adapter that can use Cloudify plugins, and it has been 
> > > tested successfully with both OpenStack and AWS so far.
> > >
> > > Unfortunately there are no instructions on how to use it. I know 
> > > just the right person to write it and will ask him to do so. :)
> > >
> > > On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran < 
> > > d.jayachand...@ericsson.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Will openstack plugin be available as part of any ARIA release ?
> > > > Is this already been looked upon or in the backlog ?
> > > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > >
> >
>

RE: Contribution for https://issues.apache.org/jira/browse/ARIA-118

[D Jayachandran]

Hi Tal,

As per the grammer in the SPEC, seems the import should take a . 
Your example dint have a  but started with respository as such.

:

  file: 

  repository: 

  namespace_uri: 

  namespace_prefix: 


With your example can we have multiple repositories ? 


Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Thursday, September 21, 2017 9:31 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118

I do suggest the repository, because it seems like the more TOSCA way to do 
this. These are special imports that are not part of the CSAR but rather 
provided in a special way by ARIA. A special repository seems to be the right 
way to handle this.

On Thu, Sep 21, 2017 at 2:40 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Tal,
>
> I had a space between the plugin and filename. The correct one would 
> like this.
>
> import
>   - plugin:openstack-1.0
>
> By this way it won't conflict with YAML convention. Do you still 
> suggest to use the repository conventions ?
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, September 20, 2017 9:38 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Contribution for https://issues.apache.org/
> jira/browse/ARIA-118
>
> I think the format you suggest is awkward in YAML. Because ":" is 
> reserved, you would have to wrap the string in quotes:
>
> imports:
>  - this/is/a/string/import.yaml
>  - this is also a string .yaml
>  - "plugins: but here we have to add quotes because of the colon.yaml"
>
> The TOSCA way to handle name ambiguity is to use a repository in the 
> long-form of the import. What we can do is create a built-in 
> repository called "plugins". So it would look like this:
>
> imports:
>  - mytypes.yaml
>  - repository: plugins
>file: openstack.yaml
>
>
>
>
>
>
> On Wed, Sep 20, 2017 at 3:49 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Tal,
> >
> > With respect to this JIRA issue.
> > I would like to contribute on the first part, which is specific to 
> > plugin implementation.
> >
> > " If a plugin contained its plugin.yaml as part of its wagon 
> > archive, then once installed, users could import the yaml file more 
> > easily using a notation such as plugins/openstack.yaml (or perhaps 
> > openstack.yaml, having the import mechanism iterate over plugins 
> > looking for this resource file or so)"
> >
> > Instead of "plugins/openstack.yaml", I would like to suggest the 
> > following
> > "plugins: openstack-"
> > Please let me know if this fine with you.
> >
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@gigaspaces.com]
> > Sent: Thursday, July 20, 2017 6:24 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Contribution for https://issues.apache.org/
> > jira/browse/ARIA-118
> >
> > It's unassigned, so I don't see why not!
> >
> > On Thu, Jul 20, 2017 at 7:41 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi,
> > >
> > > Do you have any plans on working on this JIRA issue ?
> > > https://issues.apache.org/jira/browse/ARIA-118
> > > Can we contribute on this ?
> > >
> > >
> > > Regards,
> > > DJ
> > >
> >
>

RE: Contribution for https://issues.apache.org/jira/browse/ARIA-118

[D Jayachandran]

Hi Tal,

I had a space between the plugin and filename. The correct one would like this.

import
  - plugin:openstack-1.0

By this way it won't conflict with YAML convention. Do you still suggest to use 
the repository conventions ?

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Wednesday, September 20, 2017 9:38 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118

I think the format you suggest is awkward in YAML. Because ":" is reserved, you 
would have to wrap the string in quotes:

imports:
 - this/is/a/string/import.yaml
 - this is also a string .yaml
 - "plugins: but here we have to add quotes because of the colon.yaml"

The TOSCA way to handle name ambiguity is to use a repository in the long-form 
of the import. What we can do is create a built-in repository called "plugins". 
So it would look like this:

imports:
 - mytypes.yaml
 - repository: plugins
   file: openstack.yaml






On Wed, Sep 20, 2017 at 3:49 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Tal,
>
> With respect to this JIRA issue.
> I would like to contribute on the first part, which is specific to 
> plugin implementation.
>
> " If a plugin contained its plugin.yaml as part of its wagon archive, 
> then once installed, users could import the yaml file more easily 
> using a notation such as plugins/openstack.yaml (or perhaps 
> openstack.yaml, having the import mechanism iterate over plugins 
> looking for this resource file or so)"
>
> Instead of "plugins/openstack.yaml", I would like to suggest the 
> following
> "plugins: openstack-"
> Please let me know if this fine with you.
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Tal Liron [mailto:t...@gigaspaces.com]
> Sent: Thursday, July 20, 2017 6:24 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Contribution for https://issues.apache.org/
> jira/browse/ARIA-118
>
> It's unassigned, so I don't see why not!
>
> On Thu, Jul 20, 2017 at 7:41 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > Do you have any plans on working on this JIRA issue ?
> > https://issues.apache.org/jira/browse/ARIA-118
> > Can we contribute on this ?
> >
> >
> > Regards,
> > DJ
> >
>

RE: Contribution for https://issues.apache.org/jira/browse/ARIA-118

[D Jayachandran]

Hi Tal,

With respect to this JIRA issue.
I would like to contribute on the first part, which is specific to plugin 
implementation.

" If a plugin contained its plugin.yaml as part of its wagon archive, then once 
installed, users could import the yaml file more easily using a notation such 
as plugins/openstack.yaml (or perhaps openstack.yaml, having the import 
mechanism iterate over plugins looking for this resource file or so)"

Instead of "plugins/openstack.yaml", I would like to suggest the following 
"plugins: openstack-"
Please let me know if this fine with you.


Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@gigaspaces.com] 
Sent: Thursday, July 20, 2017 6:24 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118

It's unassigned, so I don't see why not!

On Thu, Jul 20, 2017 at 7:41 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> Do you have any plans on working on this JIRA issue ?
> https://issues.apache.org/jira/browse/ARIA-118
> Can we contribute on this ?
>
>
> Regards,
> DJ
>

RE: get_artifact function usage

[D Jayachandran]

Hi Tal,

Thanks for the clarification. When we say download, does the artifact can be at 
remote location or part of the CSAR ?


Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Tuesday, September 19, 2017 9:34 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: get_artifact function usage

Sorry, I forgot to answer this. The answer is not good: sadly, there is no 
solid support for artifacts in ARIA right now beyond parsing. This function is 
currently a no-op.

Rather than just implement this function, I think it should be tackled as part 
of comprehensive support for artifacts: validation, downloading, copying, and 
verification. I think we have a JIRA for it somewhere but I can't seem to find 
it.

On Mon, Sep 18, 2017 at 10:51 PM, D Jayachandran < d.jayachand...@ericsson.com> 
wrote:

> Hi,
>
> Do we have any comments on this ?
>
> Regards,
> DJ
>
> -Original Message-
> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> Sent: Thursday, September 14, 2017 4:20 PM
> To: dev@ariatosca.incubator.apache.org
> Cc: Vaishnavi K.R <vaishnavi@ericsson.com>; Vaishali Krishnamurthy 
> < v.krishnamurt...@globallogic.com>; Rajesh Malaialagusamy < 
> r.malaialagus...@globallogic.com>
> Subject: get_artifact function usage
>
> Hi,
>
> We were looking at "get_artifact" function usage in the service template.
> It seems we don't have an implementation for it currently.
> The get_artifact function has the below grammer as per the spec.
>
> get_artifact: [ , , , 
>  ]
>
> We have few clarifications and questions over this.
>
> Do we need to use the get_artifact function only for input value 
> assignment within a specific operation ?
>
> We have 3 options before as per the grammer
>
>   1.  Retrieving artifact without specified location - without (location)
>   2.  Retrieving artifact as a local path - with location as LOCAL_FILE
>   3.  Retrieving artifact in a specified location - with location as 
> user given path How does the orchestrator need to handle these 3 
> options With 1st option as per the example , it seems the orchestrator 
> should host the provided artifact in a local path of remote URL and 
> assign that URL to input variable.
> With 2nd option the orchestrator should store the artifacts in a local 
> path (orchestrator provided ) and have that path assigned to the input 
> variable With 3rd option the orchestrator should store the artifacts 
> in a local path(user provided) and have that path assigned to the 
> input variable With these 3 options we also have an option to remove 
> the artifact after the operation execution.
> So the questions is when should the get_artifact be resolved ? Is it 
> during the parsing or during the execution ?
>
> Regards,
> DJ
>
>

RE: get_artifact function usage

[D Jayachandran]

Hi,

Do we have any comments on this ?

Regards,
DJ

-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Thursday, September 14, 2017 4:20 PM
To: dev@ariatosca.incubator.apache.org
Cc: Vaishnavi K.R <vaishnavi@ericsson.com>; Vaishali Krishnamurthy 
<v.krishnamurt...@globallogic.com>; Rajesh Malaialagusamy 
<r.malaialagus...@globallogic.com>
Subject: get_artifact function usage

Hi,

We were looking at "get_artifact" function usage in the service template. It 
seems we don't have an implementation for it currently.
The get_artifact function has the below grammer as per the spec.

get_artifact: [ , , ,  ]

We have few clarifications and questions over this.

Do we need to use the get_artifact function only for input value assignment 
within a specific operation ?

We have 3 options before as per the grammer

  1.  Retrieving artifact without specified location - without (location)
  2.  Retrieving artifact as a local path - with location as LOCAL_FILE
  3.  Retrieving artifact in a specified location - with location as user given 
path How does the orchestrator need to handle these 3 options With 1st option 
as per the example , it seems the orchestrator should host the provided 
artifact in a local path of remote URL and assign that URL to input variable.
With 2nd option the orchestrator should store the artifacts in a local path 
(orchestrator provided ) and have that path assigned to the input variable With 
3rd option the orchestrator should store the artifacts in a local path(user 
provided) and have that path assigned to the input variable With these 3 
options we also have an option to remove the artifact after the operation 
execution.
So the questions is when should the get_artifact be resolved ? Is it during the 
parsing or during the execution ?

Regards,
DJ

RE: Use & impact of role/host attribute in ARIA

[D Jayachandran]

Hi Tal,

This seems to be a better option and we can contribute for it.


Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, September 11, 2017 9:26 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Use & impact of role/host attribute in ARIA

I agree with you, DJ.

Until now, I think we wanted to make sure that the defaults would make sense 
for most uses, but indeed I agree that

I suggest that we add another configuration parameter, "remote" (boolean) to 
enforce this. If "remote" is not specified, we will use the heuristic.
If it is, we will do what the "remote" value says.

So it would look something like this:

topology_template:
  node_templates:
loadbalancer_host:
  type: openstack.Instance
  interfaces:
Standard:
  configure:
implementation:
  primary: scripts/configure.sh
  dependencies:
- remote > false

What do you think? If it makes sense to you, I can create a JIRA for it.
And you could do the PR. :)

On Mon, Sep 11, 2017 at 12:59 AM, D Jayachandran < d.jayachand...@ericsson.com> 
wrote:

> Hi,
>
> The Compute node can still be "host"  but it does not mean it has to 
> remote always ? If we can want execution-plugin to handle remote host, 
> Some-other parameter should decide if it’s a remote host or not.
>
> Regards,
> DJ
> -Original Message-
> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> Sent: Monday, September 11, 2017 11:23 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: Use & impact of role/host attribute in ARIA
>
> Hi Tal,
>
> I don’t follow how can we decide all the Compute nodes as "hosted". I 
> can still have a local compute node and I want the executor plugin to 
> run my scripts locally.
>
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, September 07, 2017 9:22 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Use & impact of role/host attribute in ARIA
>
> Really, the only important one is "host" role. For the TOSCA 
> get_property and get_attribute functions there is support for a 
> keyword called "HOST", which explicitly follows the path of outbound 
> relationships to Container capabilities (there might be several) to 
> the final Compute node. So Container and Compute play special roles in TOSCA.
>
> A related role is "feature" which exists for the 
> tosca.capabilities.Node
> (note: for the capability type, not the node type!). This is followed 
> for
> *inbound* relationships to find the "HOST". This is that nodes that 
> have relationships to the "feature" capability of any other node (it 
> is declared in tosca.nodes.Root) would be able to find their host.
>
> There are a few other roles for ARIA-specific extensions: plugins, 
> workflows, and scaling policies.
>
> We could have solved this by looking for hardcoded type names, but as 
> I said it seemed like a bad idea to me. As the TOSCA spec changes, 
> these names might change or their might be other ways to reach hosts. The 
> "role"
> keeps things generic and untied to the spec.
>
>
> On Thu, Sep 7, 2017 at 3:06 AM, D Jayachandran < 
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Tal,
> >
> > How do we conclude certain normative types play "special roles" ? I 
> > will wait for Ran to explain on the remove execution part.
> >
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Wednesday, September 06, 2017 7:05 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Use & impact of role/host attribute in ARIA
> >
> > First of all, "role" is an extension and is only used internally. It 
> > is indeed not defined by TOSCA and you shouldn't be using it yourself.
> >
> > The reason "role" exists is to avoid hardcoding functionality to 
> > type names. Certain normative types play special roles in TOSCA: 
> > certain relationships are special, as are certain capabilities, data 
> > types, etc. In order to avoid having ARIA look for a specific type 
> > name, it checks the "role" extension. Internally, "role" is 
> > inherited (and can be overridden), so that anything that inherits 
> > from tosca.nodes.Compute, for example, would also have the "host" role.
> > (For past versions of the NFV Profile, we likely had the VDU type as 
> > having "host" role, even though it did not inherit fr

get_artifact function usage

[D Jayachandran]

Hi,

We were looking at "get_artifact" function usage in the service template. It 
seems we don't have an implementation for it currently.
The get_artifact function has the below grammer as per the spec.

get_artifact: [ , , ,  ]

We have few clarifications and questions over this.

Do we need to use the get_artifact function only for input value assignment 
within a specific operation ?

We have 3 options before as per the grammer

  1.  Retrieving artifact without specified location - without (location)
  2.  Retrieving artifact as a local path - with location as LOCAL_FILE
  3.  Retrieving artifact in a specified location - with location as user given 
path
How does the orchestrator need to handle these 3 options
With 1st option as per the example , it seems the orchestrator should host the 
provided artifact in a local path of remote URL and assign that URL to input 
variable.
With 2nd option the orchestrator should store the artifacts in a local path 
(orchestrator provided ) and have that path assigned to the input variable
With 3rd option the orchestrator should store the artifacts in a local 
path(user provided) and have that path assigned to the input variable
With these 3 options we also have an option to remove the artifact after the 
operation execution.
So the questions is when should the get_artifact be resolved ? Is it during the 
parsing or during the execution ?

Regards,
DJ

RE: Support for TOSCA Simple Profile NFV 1.0

[D Jayachandran]

Hi Tal,

Thanks for the update. I will check the possibility of extending the profile 
provided by ARIA.

Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, September 11, 2017 9:40 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Support for TOSCA Simple Profile NFV 1.0

I will add that if you absolutely need this change for your own testing, you do 
not have to use ARIA's built-in NFV CSD04 Profile. You can copy the files, 
change them locally, and use a regular "import" for them. (Just make sure to 
set "tosca_definitions_version" to "tosca_simple_yaml_1_0"). If indeed you are 
sure that our implementation of CSD04 must be broken (because the spec itself 
is broken, no fault of ours), then feel free to create a PR to fix it!

On Mon, Sep 11, 2017 at 9:43 AM, Avia Efrat <a...@cloudify.co> wrote:

> We indeed removed tosca.capabilities.nfv.VirtualStorage requirement 
> from the VDU.Compute node since this capability is not defined in 
> csd04, but is just mentioned by name.
>
> The VirtualLinkable capability was in csd03, but removed from the 
> TOSCA spec in csd04. It seems as a leftover from csd03 that the 
> authors didn't properly removed all of its mentions. Regarding the 
> reasoning behind this decision, see the last paragraph of the email.
>
> tosca.relationships.nfv.VirtualLinksTo was in csd03, but removed in csd04.
> tosca.relationships.nfv.VDU.AttachedTo wasn't even in csd03.
>
> One might wonder (and indeed you wondered) how to deal with all the 
> missing parts and inconsistencies throughout the TOSCA NFV 
> specification. The answer, simply put, is that this is a work in 
> progress, still on a draft level. A lot of effort is invested 
> currently in TOSCA around the questions of creating a NFV profile that 
> combines 'naturally' with the simple TOSCA profile. This is quite an 
> intricate task to be honest. You can try to contact the authors of the 
> NFV profile for questions and possible participation.
>
>
> On Mon, Sep 11, 2017 at 4:35 PM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > HI Avia,
> >
> >
> >
> > I had to post these questions but it took sometime for me.
> >
> >
> >
> > With the csd04, I could not see the below capabilities in the spec
> >
> >
> >
> > - tosca.capabilities.nfv.VirtualStorage
> >
> > - tosca.capabilities.nfv.VirtualLinkable
> >
> >
> >
> > I think since the capability " 
> > tosca.capabilities.nfv.VirtualStorage" is missing, you had removed 
> > the requirement for "virtual_storage" for a VDU.Compute node.
> >
> > Capability "tosca.capabilities.nfv.VirtualLinkable" is one of the 
> > requirement "virtual_link" for the node type VduCpd. I see this
> requirement
> > is commented in the node type. Is this a common understanding that 
> > the VduCpd wont have a requirement on a virtual link ? I believe a 
> > VduCpd has requirement on both Compute and Virtual link as mentioned in the 
> > spec.
> >
> >
> >
> >
> >
> > Also these 2 relationships are missing too from the spec
> >
> >
> >
> > - tosca.relationships.nfv.VirtualLinksTo ( 
> > Relationship of VduCpd with a virtual link )
> >
> > - tosca.relationships.nfv.VDU.AttachedTo ( 
> > Relantionship required for virtual storage with compute node)
> >
> >
> >
> >
> >
> > How to address the missing parts from the spec ?
> >
> >
> >
> > Regards,
> >
> > DJ
> >
> >
> >
> > -Original Message-
> > From: Avia Efrat [mailto:a...@gigaspaces.com]
> > Sent: Tuesday, June 13, 2017 2:59 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Support for TOSCA Simple Profile NFV 1.0
> >
> >
> >
> > Hi DJ,
> >
> >
> >
> > Just updating that the pull request was merged.
> >
> >
> >
> > Note that there are some inconsistencies in csd04, so if you have 
> > any questions regarding our reasoning in resolving them, feel 
> > encouraged to
> ask.
> >
> >
> >
> > On Wed, Jun 7, 2017 at 10:09 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> >
> > > wrote:
> >
> >
> >
> > > Thanks for the update Avia.
> >
> > >
> >
> > > Regards,
> >
> > > DJ
> >
> > >
> >
> > > -Original Message-
> >

RE: Use & impact of role/host attribute in ARIA

[D Jayachandran]

Hi Tal,

I don’t follow how can we decide all the Compute nodes as "hosted". I can still 
have a local compute node and I want the executor plugin to run my scripts 
locally.


Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Thursday, September 07, 2017 9:22 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Use & impact of role/host attribute in ARIA

Really, the only important one is "host" role. For the TOSCA get_property and 
get_attribute functions there is support for a keyword called "HOST", which 
explicitly follows the path of outbound relationships to Container capabilities 
(there might be several) to the final Compute node. So Container and Compute 
play special roles in TOSCA.

A related role is "feature" which exists for the tosca.capabilities.Node
(note: for the capability type, not the node type!). This is followed for
*inbound* relationships to find the "HOST". This is that nodes that have 
relationships to the "feature" capability of any other node (it is declared in 
tosca.nodes.Root) would be able to find their host.

There are a few other roles for ARIA-specific extensions: plugins, workflows, 
and scaling policies.

We could have solved this by looking for hardcoded type names, but as I said it 
seemed like a bad idea to me. As the TOSCA spec changes, these names might 
change or their might be other ways to reach hosts. The "role"
keeps things generic and untied to the spec.


On Thu, Sep 7, 2017 at 3:06 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Tal,
>
> How do we conclude certain normative types play "special roles" ? I 
> will wait for Ran to explain on the remove execution part.
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, September 06, 2017 7:05 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Use & impact of role/host attribute in ARIA
>
> First of all, "role" is an extension and is only used internally. It 
> is indeed not defined by TOSCA and you shouldn't be using it yourself.
>
> The reason "role" exists is to avoid hardcoding functionality to type 
> names. Certain normative types play special roles in TOSCA: certain 
> relationships are special, as are certain capabilities, data types, 
> etc. In order to avoid having ARIA look for a specific type name, it 
> checks the "role" extension. Internally, "role" is inherited (and can 
> be overridden), so that anything that inherits from 
> tosca.nodes.Compute, for example, would also have the "host" role. 
> (For past versions of the NFV Profile, we likely had the VDU type as 
> having "host" role, even though it did not inherit from tosca.nodes.Compute).
>
> Then execution plug tries to find out if the operation is hosted 
> remotely by seeing if the node is hosted: either a host itself, or has 
> a relationship to a node that is hosted. I'll leave it to Ran to 
> explain why this needs to be the case. :)
>
>
>
> On Wed, Sep 6, 2017 at 6:27 AM, Ran Ziv <r...@cloudify.co> wrote:
>
> > (I'll let Tal take this one :P)
> >
> > On Wed, Sep 6, 2017 at 2:26 PM, D Jayachandran < 
> > d.jayachand...@ericsson.com>
> > wrote:
> >
> > > Yes, I can see that Ran. So that was my question , why was role 
> > > being added to the types ?
> > > TOSCA spec does not say about a parameter called role. I feel this 
> > > is not aligned with TOSCA spec.
> > >
> > > Regards,
> > > DJ
> > >
> > > -Original Message-
> > > From: Ran Ziv [mailto:r...@cloudify.co]
> > > Sent: Wednesday, September 06, 2017 2:16 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Use & impact of role/host attribute in ARIA
> > >
> > > This is where the execution plugin decides whether to run locally 
> > > or remotely (ssh):
> > > https://github.com/apache/incubator-ariatosca/blob/0.1.
> > > 1/aria/orchestrator/execution_plugin/instantiation.py#L42
> > >
> > > This is indeed related to the "host" role definition.
> > >
> > > Here you can see the assignment of the "host" role to the Compute type:
> > > https://github.com/apache/incubator-ariatosca/blob/
> > > 1e883c57abb733b10e13f0b7005cf564886d3fb1/extensions/aria_
> > > extension_tosca/profiles/tosca-simple-1.0/nodes.yaml#L63
> > >
> > >
> > > Ran
> > >
> > > On Wed, Sep 6, 2017 at 10:07 AM, D Jayachandran < 
> > > d.jayachand...@ericsson.com
>

RE: Use & impact of role/host attribute in ARIA

[D Jayachandran]

Hi Tal,

How do we conclude certain normative types play "special roles" ? I will wait 
for Ran to explain on the remove execution part.


Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Wednesday, September 06, 2017 7:05 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Use & impact of role/host attribute in ARIA

First of all, "role" is an extension and is only used internally. It is indeed 
not defined by TOSCA and you shouldn't be using it yourself.

The reason "role" exists is to avoid hardcoding functionality to type names. 
Certain normative types play special roles in TOSCA: certain relationships are 
special, as are certain capabilities, data types, etc. In order to avoid having 
ARIA look for a specific type name, it checks the "role" extension. Internally, 
"role" is inherited (and can be overridden), so that anything that inherits 
from tosca.nodes.Compute, for example, would also have the "host" role. (For 
past versions of the NFV Profile, we likely had the VDU type as having "host" 
role, even though it did not inherit from tosca.nodes.Compute).

Then execution plug tries to find out if the operation is hosted remotely by 
seeing if the node is hosted: either a host itself, or has a relationship to a 
node that is hosted. I'll leave it to Ran to explain why this needs to be the 
case. :)



On Wed, Sep 6, 2017 at 6:27 AM, Ran Ziv <r...@cloudify.co> wrote:

> (I'll let Tal take this one :P)
>
> On Wed, Sep 6, 2017 at 2:26 PM, D Jayachandran < 
> d.jayachand...@ericsson.com>
> wrote:
>
> > Yes, I can see that Ran. So that was my question , why was role 
> > being added to the types ?
> > TOSCA spec does not say about a parameter called role. I feel this 
> > is not aligned with TOSCA spec.
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Ran Ziv [mailto:r...@cloudify.co]
> > Sent: Wednesday, September 06, 2017 2:16 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Use & impact of role/host attribute in ARIA
> >
> > This is where the execution plugin decides whether to run locally or 
> > remotely (ssh):
> > https://github.com/apache/incubator-ariatosca/blob/0.1.
> > 1/aria/orchestrator/execution_plugin/instantiation.py#L42
> >
> > This is indeed related to the "host" role definition.
> >
> > Here you can see the assignment of the "host" role to the Compute type:
> > https://github.com/apache/incubator-ariatosca/blob/
> > 1e883c57abb733b10e13f0b7005cf564886d3fb1/extensions/aria_
> > extension_tosca/profiles/tosca-simple-1.0/nodes.yaml#L63
> >
> >
> > Ran
> >
> > On Wed, Sep 6, 2017 at 10:07 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi,
> > >
> > > I just noticed the "role" attribute is added for different "capability"
> > > and "node" types in ARIA profiles. There is no such role with the 
> > > TOSCA spec.
> > > Why is this been added in the profiles ? What is the use of them ?
> > >
> > > I faced an issue when I run a local script as part of the 
> > > Interface operation. The script was provided to the execution 
> > > plugin as "run_script_with_ssh" rather than "run_script_locally".
> > > The "role" seemed to have a saying on deciding this. Based on this 
> > > role a host is being added to any node instance. With the host 
> > > being set a script is configured either as " run_script_with_ssh" 
> > > rather than "run_script_locally".
> > >
> > > So I want to understand under which cicumstances is a host being 
> > > added to a node and which decided if the script execution is local or ssh 
> > > ?
> > >
> > >
> > > Regards,
> > > DJ
> > >
> >
>

RE: Use & impact of role/host attribute in ARIA

[D Jayachandran]

Yes, I can see that Ran. So that was my question , why was role being added to 
the types ?
TOSCA spec does not say about a parameter called role. I feel this is not 
aligned with TOSCA spec.

Regards,
DJ

-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co] 
Sent: Wednesday, September 06, 2017 2:16 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Use & impact of role/host attribute in ARIA

This is where the execution plugin decides whether to run locally or remotely 
(ssh):
https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/orchestrator/execution_plugin/instantiation.py#L42

This is indeed related to the "host" role definition.

Here you can see the assignment of the "host" role to the Compute type:
https://github.com/apache/incubator-ariatosca/blob/1e883c57abb733b10e13f0b7005cf564886d3fb1/extensions/aria_extension_tosca/profiles/tosca-simple-1.0/nodes.yaml#L63


Ran

On Wed, Sep 6, 2017 at 10:07 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> I just noticed the "role" attribute is added for different "capability"
> and "node" types in ARIA profiles. There is no such role with the 
> TOSCA spec.
> Why is this been added in the profiles ? What is the use of them ?
>
> I faced an issue when I run a local script as part of the Interface 
> operation. The script was provided to the execution plugin as 
> "run_script_with_ssh" rather than "run_script_locally".
> The "role" seemed to have a saying on deciding this. Based on this 
> role a host is being added to any node instance. With the host being 
> set a script is configured either as " run_script_with_ssh" rather 
> than "run_script_locally".
>
> So I want to understand under which cicumstances is a host being added 
> to a node and which decided if the script execution is local or ssh ?
>
>
> Regards,
> DJ
>

RE: Service Composition / Substitution Mapping

[D Jayachandran]

Thanks Tal. I agree this needs to taken up with OASIS.

Having said that ,there is statement in TOSCA Spec 2.9 

" In TOSCA templates, nodes are either:

· Concrete: meaning that they have a deployment and/or one or more 
implementation artifacts that are declared on the “create” operation of the 
node’s Standard lifecycle interface, or they are

· Abstract: where the template describes the node type along with its 
required capabilities and properties that must be satisfied."

I thought if the above statement would anyway help us in identifying an 
abstract node.


Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Tuesday, September 05, 2017 8:30 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Service Composition / Substitution Mapping

On Tue, Sep 5, 2017 at 5:33 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

>  Hence I wanted to know if there is any possibility of identifying an 
> abstract type (during parsing )so that we need not import or define 
> the custom node type in my service template.
>

In my opinion, the import of the abstract type is necessary. TOSCA offers no 
alternative, and I don't see how ARIA would be able to guess that this type is 
abstract nor have any notion where to find the type. I think that such 
usability problems we find in the mechanism need to be addressed at OASIS. 
Perhaps we can make TOSCA 1.2 easier to use with substitution mapping. For now, 
though, I think ARIA should adhere to the TOSCA 1.0 standard as closely as 
possible.

Use & impact of role/host attribute in ARIA

[D Jayachandran]

Hi,

I just noticed the "role" attribute is added for different "capability" and 
"node" types in ARIA profiles. There is no such role with the TOSCA spec.
Why is this been added in the profiles ? What is the use of them ?

I faced an issue when I run a local script as part of the Interface operation. 
The script was provided to the execution plugin as "run_script_with_ssh" rather 
than "run_script_locally".
The "role" seemed to have a saying on deciding this. Based on this role a host 
is being added to any node instance. With the host being set a script is 
configured either as " run_script_with_ssh" rather than "run_script_locally".

So I want to understand under which cicumstances is a host being added to a 
node and which decided if the script execution is local or ssh ?


Regards,
DJ

RE: Service Composition / Substitution Mapping

[D Jayachandran]

> > are satisfied (considering both top level and substituting 
> > template), the substitution mapping is not considered successful, and the 
> > instantiation fails.
> >
> > If that is the case, it makes sense to go ahead and try the next 
> > substitution template that fits the type, and continue like so until 
> > we find a substitution where all the requirements are satisfied 
> > during instantiation.
> >
> > At this point you may be wondering, "what if the instantiation was 
> > successful, but the source of the substitution template wasn't the 
> > one
> that
> > *I* wanted?". Well, You have to think about this issue in 
> > substitution mapping terms. that is, when you use an abstract node, 
> > actually what you are saying is "I want something of type t, the has 
> > the capabilities c,
> and
> > requires r. regarding the internals, I don't care, I just want it to
> work".
> > So actually, selecting a specific substituting template (as long as 
> > the type, the requirements and the capabilities are as expected, of 
> > course),
> is
> > somewhat against the spirit of the substitution mapping feature.
> >
> > 2) I'm sorry, but I didn't get to the bottom of your question. Could 
> > you elaborate a bit more, and include a small example?
> >
> >
> >
> >
> > On Thu, Aug 31, 2017 at 11:35 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com> wrote:
> >
> > > Hi,
> > >
> > > With respect to substituting stored service templates, I have few
> things
> > > to be clarified
> > >
> > > 1) Handling substitution when multiple service templates matches 
> > > for
> the
> > > abstract node type .
> > > Would the 1st match would be used for substitution  or Are 
> > > we looking at policy to enable user to select particular service 
> > > templates
> > for
> > > substitution with multiple service templates ?
> > > 2) Custom node types as abstract node type.
> > > With custom node types as abstract node type, there seems 
> > > to
> be a
> > > need to implicitly import that custom node type in our top level
> service
> > > template so that the parser recognizes this custom type.
> > > Assuming the abstract node type would be substituted from 
> > > a
> > stored
> > > substituting service template, we need to at least import the 
> > > custom
> node
> > > types and have it part of the same CSAR package.
> > > Would this be a challenge for the top-level service 
> > > template author in including and importing the custom node types 
> > > as abstraction
> ?
> > or
> > > Is this how we are looking at custom node types ?
> > > Is it possible to identify an abstract node during parsing 
> > > ,
> such
> > > as if it does not contain any implementation ( The SPEC does not 
> > > say anything on this )?
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: Ran Ziv [mailto:r...@cloudify.co]
> > > Sent: Wednesday, August 16, 2017 6:19 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Service Composition / Substitution Mapping
> > >
> > > I agree, especially when the benefit of being able to use an 
> > > existing service - yet only one which hasn't been deployed via a 
> > > workflow -
> > doesn't
> > > seem all that interesting IMO.
> > >
> > > Another concern I could add to the ones you've mentioned is the
> service's
> > > inputs - the substituting template's inputs should be received via 
> > > the properties of the abstract node in the top level service 
> > > template. If
> the
> > > service already exists, these inputs would not be passed as expected.
> > >
> > > Ran
> > >
> > > On Wed, Aug 16, 2017 at 3:25 PM, D Jayachandran < 
> > > d.jayachand...@ericsson.com
> > > > wrote:
> > >
> > > > Hi Ran,
> > > >
> > > > When Tal mentioned about "substituting service", I thought it 
> > > > was about the services which dint have any associated
> executions/workflows
> > > triggered.
> > > > Am also in favor of  "substituting service templates" rather 
> > > > than "substituting service".
> > > > With "substituting service" approach (when

RE: Service Composition / Substitution Mapping

[D Jayachandran]

Hi,

With respect to substituting stored service templates, I have few things to be 
clarified

1) Handling substitution when multiple service templates matches for the 
abstract node type .
Would the 1st match would be used for substitution  or Are we looking 
at policy to enable user to select particular service templates for 
substitution with multiple service templates ?
2) Custom node types as abstract node type. 
With custom node types as abstract node type, there seems to be a need 
to implicitly import that custom node type in our top level service template so 
that the parser recognizes this custom type. 
Assuming the abstract node type would be substituted from a stored 
substituting service template, we need to at least import the custom node types 
and have it part of the same CSAR package. 
Would this be a challenge for the top-level service template author in 
including and importing the custom node types as abstraction ? or Is this how 
we are looking at custom node types ?
Is it possible to identify an abstract node during parsing , such as if 
it does not contain any implementation ( The SPEC does not say anything on this 
)? 

Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co] 
Sent: Wednesday, August 16, 2017 6:19 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Service Composition / Substitution Mapping

I agree, especially when the benefit of being able to use an existing service - 
yet only one which hasn't been deployed via a workflow - doesn't seem all that 
interesting IMO.

Another concern I could add to the ones you've mentioned is the service's 
inputs - the substituting template's inputs should be received via the 
properties of the abstract node in the top level service template. If the 
service already exists, these inputs would not be passed as expected.

Ran

On Wed, Aug 16, 2017 at 3:25 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Ran,
>
> When Tal mentioned about "substituting service", I thought it was 
> about the services which dint have any associated executions/workflows 
> triggered.
> Am also in favor of  "substituting service templates" rather than 
> "substituting service".
> With "substituting service" approach (when the service is not 
> instantiated), I see some open points
> - In a multi-user scenario, what will happen when a service is 
> composed using the substituting service and at the sametime a  
> workflow is triggered for the substituting service. ?
> - Is it okay to delete(dissolve) the substituting service 
> after it is used to create the composed service. ?
>
> Starting with it might be a good idea to only have "substituting 
> service templates" approach.
>
> Regards,
> DJ
> -Original Message-
> From: Ran Ziv [mailto:r...@cloudify.co]
> Sent: Wednesday, August 16, 2017 4:29 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Service Composition / Substitution Mapping
>
> I'd say right now we're looking at "static service composition" which 
> is only about "substituting service templates", not "substituting 
> service". If a service is already running, it will not be used.
>
> I think what Tal meant was that each service template - whether the 
> top level one or one of the substituting templates - needs to resolve 
> its inner reqs internally first, and then resolve substitution 
> reqs across service templates.
>
>
> On Wed, Aug 16, 2017 at 12:00 PM, D Jayachandran < 
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Tal,
> >
> > Thanks for organizing the points.
> > So if I understand correctly we are looking only at "Static service 
> > composition" which includes "substituting service template" and 
> > "substituting service".
> >
> > As you said with "substituting service template" approach ,we will 
> > have all the nodes aggregated from other service templates and a 
> > single workflow would be triggered to perform life-cycle operation 
> > on
> all the nodes.
> > Am not sure why the workflows needs to be "boundary aware" for nodes 
> > being substituted ? I see nodes are already part of the composed 
> > service, Could you please help me understand this ?
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Saturday, August 12, 2017 4:52 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Service Composition / Substitution Mapping
> >
> > You are correct -- to participate in this "multi-VIM" scenario, the 
> > Opensta

RE: pip executable expected as part of plugin install.

[D Jayachandran]

Even if we fix the issue in ARIA. Wagon library still uses the same logic in 
finding the pip path and it is wrong. 
Am not sure how to fix this with wagon.

Regards,
DJ
-Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Thursday, August 03, 2017 5:00 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: pip executable expected as part of plugin install.

Thanks Avia, I will open an issue.

Regards,
DJ

-Original Message-
From: Avia Efrat [mailto:a...@cloudify.co]
Sent: Thursday, August 03, 2017 4:01 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: pip executable expected as part of plugin install.

Hi DJ,
It seems you are correct, I don't see a reason for not using the pip library.
Maybe it was that way since we didn't want to add pip as a dependency 
explicitly (this code is from the beginning of ARIA).

Feel free to open an issue about that =)

On Wed, Aug 2, 2017 at 10:19 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> Am using a Ubuntu version of linux for my development and ARIA does 
> not find the correct path of pip during the plugin install.
> To be precise this happens when pip freeze is executed.
>
> @staticmethod
> def _pip_freeze():
> """Run pip freeze in current environment and return the output"""
> bin_dir = 'Scripts' if os.name == 'nt' else 'bin'
> pip_path = os.path.join(sys.prefix, bin_dir,
> 'pip{0}'.format('.exe' if os.name == 'nt'
> else ''))
> pip_freeze = subprocess.Popen([pip_path, 'freeze'],
> stdout=subprocess.PIPE)
> pip_freeze_output, _ = pip_freeze.communicate()
> assert not pip_freeze.poll()
> return pip_freeze_output
>
> Now the question is why are we executing a pip command directly and 
> not using pip as a library.
>
>
> Regards,
> DJ
>

RE: Service Composition / Substitution Mapping

[D Jayachandran]

Hi Ran,

When Tal mentioned about "substituting service", I thought it was about the 
services which dint have any associated executions/workflows triggered.
Am also in favor of  "substituting service templates" rather than "substituting 
service".
With "substituting service" approach (when the service is not instantiated), I 
see some open points
- In a multi-user scenario, what will happen when a service is composed 
using the substituting service and at the sametime a  workflow is triggered for 
the substituting service. ?
- Is it okay to delete(dissolve) the substituting service after it is 
used to create the composed service. ? 

Starting with it might be a good idea to only have "substituting service 
templates" approach.

Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co] 
Sent: Wednesday, August 16, 2017 4:29 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Service Composition / Substitution Mapping

I'd say right now we're looking at "static service composition" which is only 
about "substituting service templates", not "substituting service". If a 
service is already running, it will not be used.

I think what Tal meant was that each service template - whether the top level 
one or one of the substituting templates - needs to resolve its inner reqs 
internally first, and then resolve substitution reqs across service 
templates.


On Wed, Aug 16, 2017 at 12:00 PM, D Jayachandran < d.jayachand...@ericsson.com> 
wrote:

> Hi Tal,
>
> Thanks for organizing the points.
> So if I understand correctly we are looking only at "Static service 
> composition" which includes "substituting service template" and 
> "substituting service".
>
> As you said with "substituting service template" approach ,we will 
> have all the nodes aggregated from other service templates and a 
> single workflow would be triggered to perform life-cycle operation on all the 
> nodes.
> Am not sure why the workflows needs to be "boundary aware" for nodes 
> being substituted ? I see nodes are already part of the composed 
> service, Could you please help me understand this ?
>
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Saturday, August 12, 2017 4:52 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Service Composition / Substitution Mapping
>
> You are correct -- to participate in this "multi-VIM" scenario, the 
> Openstack plugin would have to know how to translate the TOSCA 
> properties to a flavor ID. This could all be done in 100% TOSCA via 
> policies (say, an aria.Openstack).
>
> Doing this automatically might not be a good idea, or even necessary.
> Worst case is you get a validation error if the ARIA plugin can't find 
> a flavor in the table to match your requirements, in which you case 
> you can go and manually find the right ID and add it to the table.
>
> And I agree about being fine with imperfection: the rule of thumb for 
> our work is always to allow for sensible defaults even if no explicit 
> policy is given.
>
> Anyway, we've gone way off the topic of this thread. We can talk about 
> it more once it comes closer to an implementation.
>
> On Fri, Aug 11, 2017 at 3:52 PM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Interesting.  Take Openstack (please ).  If you model a 
> > compute OS as explicitly as you like, there still has to be a "match"
> > to an Openstack image ID.  Or are you saying you must supply the 
> > image
> ID for
> > OSs.   Likewise, you can't supply RAM and CPUs without a flavor ID.
> > Openstack does allow for custom flavors, but I doubt the plugin is 
> > doing that.  Much better to have a "caps-init" interface in some low 
> > down base type that can be triggered at service creation to support 
> > reqs/caps (IMHO).  Then the plugin can verify whether the service 
> > can be construct based on fuzzy constraints.  Maybe this is a case 
> > that the "general solution" is a nightmare of complexity, but having 
> > a plugin scan the available flavors to make sure a requirement can 
> > be met doesn't seem that tough.  If TOSCA provided a formal 
> > lifecycle interface for it, then orchestrators or just plugins could 
> > determine how tricky they wanted to be.  IOW, let not the perfect be 
> > the enemy of
> the good.
> >
> > DeWayne
> >
> >
> > On Fri, Aug 11, 2017 at 1:26 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> > > OK, that's a whole different can of worms. :)
> > >
> > > TOSCA's C

RE: Service Composition / Substitution Mapping

[D Jayachandran]

Hi Tal,

Thanks for organizing the points.
So if I understand correctly we are looking only at "Static service 
composition" which includes "substituting service template" and "substituting 
service".

As you said with "substituting service template" approach ,we will have all the 
nodes aggregated from other service templates and a single workflow would be 
triggered to perform life-cycle operation on all the nodes.
Am not sure why the workflows needs to be "boundary aware" for nodes being 
substituted ? I see nodes are already part of the composed service, Could you 
please help me understand this ?


Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Saturday, August 12, 2017 4:52 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Service Composition / Substitution Mapping

You are correct -- to participate in this "multi-VIM" scenario, the Openstack 
plugin would have to know how to translate the TOSCA properties to a flavor ID. 
This could all be done in 100% TOSCA via policies (say, an aria.Openstack).

Doing this automatically might not be a good idea, or even necessary. Worst 
case is you get a validation error if the ARIA plugin can't find a flavor in 
the table to match your requirements, in which you case you can go and manually 
find the right ID and add it to the table.

And I agree about being fine with imperfection: the rule of thumb for our work 
is always to allow for sensible defaults even if no explicit policy is given.

Anyway, we've gone way off the topic of this thread. We can talk about it more 
once it comes closer to an implementation.

On Fri, Aug 11, 2017 at 3:52 PM, DeWayne Filppi  wrote:

> Interesting.  Take Openstack (please ).  If you model a 
> compute OS as explicitly as you like, there still has to be a "match" 
> to an Openstack image ID.  Or are you saying you must supply the image ID for
> OSs.   Likewise, you can't supply RAM and CPUs without a flavor ID.
> Openstack does allow for custom flavors, but I doubt the plugin is 
> doing that.  Much better to have a "caps-init" interface in some low 
> down base type that can be triggered at service creation to support 
> reqs/caps (IMHO).  Then the plugin can verify whether the service can 
> be construct based on fuzzy constraints.  Maybe this is a case that 
> the "general solution" is a nightmare of complexity, but having a 
> plugin scan the available flavors to make sure a requirement can be 
> met doesn't seem that tough.  If TOSCA provided a formal lifecycle 
> interface for it, then orchestrators or just plugins could determine 
> how tricky they wanted to be.  IOW, let not the perfect be the enemy of the 
> good.
>
> DeWayne
>
>
> On Fri, Aug 11, 2017 at 1:26 PM, Tal Liron  wrote:
>
> > OK, that's a whole different can of worms. :)
> >
> > TOSCA's Compute capabilities (Container and OperatingSystem) are
> explicit.
> > You specify which OS you want, how much RAM you want, how many CPUs, etc.
> > ARIA's explicit node types (for example, the AWS Compute node) are
> likewise
> > explicit. So there is not querying here: the plugin will attempt to 
> > spin
> up
> > exactly the virtual machine you asked for. If it fails, the workflow 
> > will fail.
> >
> > This is not good enough, I think, for real world scenarios. There 
> > are two possible solutions:
> >
> > 1) Support ranges or fallbacks. So instead of saying "I need 4 GB of RAM"
> > you can say "I would like 4 GB of RAM, but 2 GB would also be OK."
> There's
> > no easy way to do this now without totally changing how the 
> > capability types are designed. But, it may be possible to override 
> > this via
> policies.
> > So, the capabilities would perhaps specify the minimal requirements,
> while
> > policies specify preferences. Some aspects of this were discussed in 
> > the OPEN-O project. DeWayne, has any of this survived in ONAP, or 
> > have we not reached that point in the discussion yet?
> >
> > 2) Incorporate this into the bigger topic of resource orchestration.
> This a
> > huge challenge for the industry. The problem field contains not just 
> > "I need X amount of RAM" but also "I want all my virtual machines 
> > and containers running on the same high-performance network backend 
> > and have these two nodes on the same bare-metal machine or at least 
> > in the same
> data
> > center rack with a NUMA interconnect, and I also don't want all this 
> > to cost more that $100 per hour." That's not crazy: these are real 
> > world requirements for high-performance VNFs and service chaining. 
> > Resource orchestration requires a full map of what is available in 
> > the data
> centers,
> > a negotiation-based algorithm for properly allocating and placing 
> > resources, connection to billing services, etc. Of course resource 
> > orchestration is not within the scope of ARIA, but it would be great 
> > for ARIA to have plugins for them (and TOSCA be able to model 
> > 

RE: Service Composition / Substitution Mapping

[D Jayachandran]

Hi Tal,

Thanks for the explanation.

So we have 2 options when the reqs-caps are not met within the same 
service-template

Option 1:
To look at satisfying nodes present in a substituting service, Have 
these nodes part of the newly created service and remove the substituting 
service(nodes with different ID's. Also we are very much in favor of  UUID )
With this approach I guess the substituting service should not have any 
associated workflows running. If at all an workflow execution is already 
triggered I hope this service will not be considered for substitution.
I hope this is the correct approach when we are looking at a service 
for the substitution

Option 2:
While creating a service look at the req-caps at the service-template 
level and create a service including the nodes provided by the substituting 
service-template. With this approach there would not be any   service created 
from the service-template which is providing the substitution functionality. 
The service-template would remain the same but only the service would be added 
with extra nodes.

Are you considering both option 1 & 2 for the implementation ? If not which one 
do you feel which take priority. I see option 2 at this stage could be the best 
possible approach
Also could you please let me know a tentative time for this feature to be 
available?


Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Thursday, August 10, 2017 10:09 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Service Composition / Substitution Mapping

Thanks for the feedback, DJ. What I wrote was just ideas for now, we're still 
in the investigation phase and haven't implemented anything yet.

1. The reqs-and-caps engine by default will always look for satisfiable
> capabilities within the currently instantiated service. HOWEVER, if 
> such a capability is not present, the option is there to look for 
> another instantiated service that exposes the capabilities in substitution 
> mappings.
> [DJ] - When you say option is there to look for another 
> instantiated service is this an available option with current ARIA ?
>  - When you say instantiated service, is it the 
> service or the real world service ?
>  - I think the 3rd point of yours is related to this 
> service level mapping. When you say a special node would be added to 
> the current service, will that node be unique across service A and 
> service B(instantiated service) ? Will a life-cycle operation would be 
> called for that node which is added to service A as part of the workflow 
> execution ?
>

I don't think it's reasonable for ARIA to work with a "real world service"
if it hasn't been modeled yet in some way. I do have a dream of someday having 
such a tool: take an existing cloud service and produce a basic TOSCA service 
*and* service template for it. But for now I think it's reasonable to expect 
the user to at least model the whole "real world"
service as some kind of logical node.

The question you ask about lifecycle operations are the right ones. In my 
opinion, the new "composed service" should be a service instance in every 
respect, so workflows would indeed happen on all nodes, including the 
sub-services that were added. Otherwise, why do composition at all? The whole 
point is to combine everything together.

An interesting question is what happens to nodes after that get "composed"
into another service. From what I say above, it means their service IDs should 
change, and in fact the original service would disappear. (By the way, things 
like this are another reason I prefer UUIDs for nodes rather than have them be 
sequential within the service: nodes should be allowed to move around between 
services.)

The only way you would know that these added nodes came from a another service 
template is by following their node_template_fk to their service_template_fk. 
Otherwise they are all in the same service.


> 2. If we DON'T have another instantiated service, but DO have a 
> service template that could fit the bill, perhaps we need to 
> instantiate that other service first. One obvious option is to do this 
> automatically. But I feel like this can create unforeseen consequences 
> -- for example, some dummy test template that someone happened to have 
> in the database might get instantiated by mistake. Also, it might need 
> to trigger multiple install workflows at once... a big mess. So I 
> suggest that instead we provide a very detailed validation error here 
> saying that the requirement cannot be satisfied, HOWEVER there exist 
> service templates A, B, and C that can substitute for us, so maybe the 
> nice user would like to instantiate them first? This seems very reasonable to 
> me.
> [DJ] - Just to understand more on this, Let us assume we have 
> service-template A and service-template B. Am trying to create a 
> service A from 

RE: Service Composition / Substitution Mapping

[D Jayachandran]

Hi Tal,

I remember we had the conversion of substitution mapping sometime ago, where we 
agreed upon of looking at available service-models(service-templates) when we 
dont find a satisfiable capability within our service. I just want to make sure 
if we are on the same page as the implementation work is started for this. Also 
I have few questions with respect to the points you had put forth. Please find 
my comments in-line against each of your points.

1. The reqs-and-caps engine by default will always look for satisfiable 
capabilities within the currently instantiated service. HOWEVER, if such a 
capability is not present, the option is there to look for another instantiated 
service that exposes the capabilities in substitution mappings.
[DJ] - When you say option is there to look for another instantiated 
service is this an available option with current ARIA ?
 - When you say instantiated service, is it the service or the 
real world service ?
 - I think the 3rd point of yours is related to this service 
level mapping. When you say a special node would be added to the current 
service, will that node be unique across service A and service B(instantiated 
service) ? Will a life-cycle operation would be called for that node which is 
added to service A as part of the workflow execution ? 


2. If we DON'T have another instantiated service, but DO have a service 
template that could fit the bill, perhaps we need to instantiate that other 
service first. One obvious option is to do this automatically. But I feel like 
this can create unforeseen consequences -- for example, some dummy test 
template that someone happened to have in the database might get instantiated 
by mistake. Also, it might need to trigger multiple install workflows at 
once... a big mess. So I suggest that instead we provide a very detailed 
validation error here saying that the requirement cannot be satisfied, HOWEVER 
there exist service templates A, B, and C that can substitute for us, so maybe 
the nice user would like to instantiate them first? This seems very reasonable 
to me.
[DJ] - Just to understand more on this, Let us assume we have 
service-template A and service-template B. Am trying to create a service A from 
service-template A. One of the node is abstract and this capability is provided 
by node from service-template B. 
- Now I assume service A will have node contributed by 
service-template B and also its nodes. Will this approach I don't see a need 
for multiple workflows.
- Or is it like service B would also be created automatically. 
In that case how would the workflow be called for service B ?
- As you stated we have this challenge with multiple 
service-template providing the same capabilities on which one to use.
- Finally am not getting the exact meaning of the last 
statement of yours "HOWEVER there exist service templates A, B, and C that can 
substitute for us, so maybe the nice user would like to instantiate them first? 
This seems very reasonable to me". I assume you are talking having a provision 
where the user can mention the service-template to be used 

3. If indeed another service satisfies this, a special node is added to the 
current service (with the correct type -- but without a service template 
foreign key), which serves as a proxy of the other service template. I'm not 
sure how we would mark this exactly. We can't use the service_fk field, because 
it's still in our current service. So perhaps there's need of a new fk field, 
maybe substituted_service_fk?

The above might be "sensible defaults," but it seems to me that users really 
need control over this. So I propose to add a new aria.Composition policy that 
would let you provide hints for this mechanism. For example, you might want to 
"filter" the target service by service template name and even by metadata in 
the service template. For example, you might want to require version 1.2.2 of a 
specific service, no less.

Regards,
DJ
-Original Message-
From: Avia Efrat [mailto:a...@cloudify.co] 
Sent: Wednesday, August 09, 2017 6:28 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Service Composition / Substitution Mapping

Currently, the support for substitution mapping is extremely limited. the 
substitution_mapping section is parsed and validated, but nothing more.

However, supporting this feature (and hence, allowing for service
composition) is of high priority. Currently, we are at the the designing phase 
- going over the spec to identify vague and ambiguous parts, and consolidating 
TOSCA's pov regarding substitution mapping with the current ARIA implementation.

Relevant Jira issue:
https://issues.apache.org/jira/browse/ARIA-292

On Tue, Aug 8, 2017 at 11:03 PM, Steve Baillargeon < 
steve.baillarg...@ericsson.com> wrote:

> Hi
> I have looked at the data you have provided.
> I am trying to catch up 

RE: Version support for different TOSCA types

[D Jayachandran]

Ok Tal, I agree with having a property datatype as version and using them in my 
implementations. But to re-iterate I see the support for version metadata for 
different types ( node, artifact, attribute, capability, requirements ) in 
TOSCA 1.0 profile too. You can check the section starting from "3.6.3 Artifact 
Type". 

Example from SPEC:

3.6.8.2
Grammar
Node Types
have following grammar
:
<
node_type_name
>:  
derived_from: <
parent_node_type_name
> 
version: <
version_number
>
description: <
node_type_description
>
properties:
<
property_definitions
>
attributes:
<
attribute_definitions
>
requirements: 
-
<
requirement_definitions
>
capabilities:
<
capability_definitions
>
interfaces:
<
interface_definitions
> 
artifacts:
<
artifact_definitions
>

Even am trying to understand the use-case which can be mapped to version 
support with each of types. 

Is it like we can have same custom node types with different version in 
my service template ? 
In that case how can the node template choose a particular version of 
the custom node type ? 
Or Is the version only for the template author to track changes about 
custom types over time ?


Regards,
DJ

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Tuesday, August 08, 2017 12:11 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Version support for different TOSCA types

There is no special use of versions in TOSCA 1.0: it is up to you to define 
properties or attributes or inputs of the "version" data type and do with those 
as you please in your operation implementations. TOSCA 1.1 takes it a step 
further and provides standardized metadata to nodes.

It seems that you have a particular use case in mind. Can you elaborate it to 
us? Perhaps we can together brainstorm a solution,

On Tue, Aug 8, 2017 at 1:05 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Tal,
>
> I agree version is now looked upon as a "data type" now. But does the 
> orchestrator has any scope when it comes to comparing node types or 
> templates depending on the version specified ?
> Am more interested in this statement where the version is looked upon 
> as a parameter when defining different types "TOSCA supports the 
> concept of “reuse” of type definitions, as well as template 
> definitions which could be version and change over time. "
>
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Monday, August 07, 2017 9:04 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Version support for different TOSCA types
>
> OK, you are referring to the "version" data type, and it is fully 
> supported in ARIA, which includes:
>
> 1. Strict adherence to the (rather odd) specification and its regex 2.
> Proper support for TOSCA comparative constraints for versions 
> (greater_than, lesser_than, etc.) 3. Comparisons also work properly in 
> Python when comparing version instances
>
> On Mon, Aug 7, 2017 at 12:22 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Tal,
> >
> > I was referring to the section 3.2.2  in TOSCA 1.0. It seems the 
> > version is part of both TOSCA 1.0 and TOSCA 1.1
> >
> > http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.pdf
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Friday, August 04, 2017 9:39 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Version support for different TOSCA types
> >
> > I think you are referring to TOSCA 1.1, which is on the roadmap but 
> > not supported yet.
> >
> > You can of course create your own "version" property or attribute 
> > for node types in TOSCA 1.0.
> >
> > On Fri, Aug 4, 2017 at 7:05 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com>
> > wrote:
> >
> > > Hi,
> > >
> > > The TOSCA spec mentions about the version as a keyname for 
> > > different type definitions(Node, Group, Interface, Artifacts, Data 
> > > .. .) As mentioned in spec this is for the re-use of different 
> > > types . Does ARIA support the version at this stage ? What is the 
> > > scope of orchestrator when it comes to the version support ?
> > >
> > >
> > >
> > > Regards,
> > > DJ
> > >
> >
>

RE: Version support for different TOSCA types

[D Jayachandran]

Hi Tal,

I agree version is now looked upon as a "data type" now. But does the 
orchestrator has any scope when it comes to comparing node types or templates 
depending on the version specified ?
Am more interested in this statement where the version is looked upon as a 
parameter when defining different types "TOSCA supports the concept of “reuse” 
of type definitions, as well as template definitions which could be version and 
change over time. "


Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, August 07, 2017 9:04 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Version support for different TOSCA types

OK, you are referring to the "version" data type, and it is fully supported in 
ARIA, which includes:

1. Strict adherence to the (rather odd) specification and its regex 2. Proper 
support for TOSCA comparative constraints for versions (greater_than, 
lesser_than, etc.) 3. Comparisons also work properly in Python when comparing 
version instances

On Mon, Aug 7, 2017 at 12:22 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Tal,
>
> I was referring to the section 3.2.2  in TOSCA 1.0. It seems the 
> version is part of both TOSCA 1.0 and TOSCA 1.1
>
> http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.pdf
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Friday, August 04, 2017 9:39 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Version support for different TOSCA types
>
> I think you are referring to TOSCA 1.1, which is on the roadmap but 
> not supported yet.
>
> You can of course create your own "version" property or attribute for 
> node types in TOSCA 1.0.
>
> On Fri, Aug 4, 2017 at 7:05 AM, D Jayachandran < 
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi,
> >
> > The TOSCA spec mentions about the version as a keyname for different 
> > type definitions(Node, Group, Interface, Artifacts, Data .. .) As 
> > mentioned in spec this is for the re-use of different types . Does 
> > ARIA support the version at this stage ? What is the scope of 
> > orchestrator when it comes to the version support ?
> >
> >
> >
> > Regards,
> > DJ
> >
>

RE: Version support for different TOSCA types

[D Jayachandran]

Hi Tal,

I was referring to the section 3.2.2  in TOSCA 1.0. It seems the version is 
part of both TOSCA 1.0 and TOSCA 1.1

http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.pdf
 

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Friday, August 04, 2017 9:39 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Version support for different TOSCA types

I think you are referring to TOSCA 1.1, which is on the roadmap but not 
supported yet.

You can of course create your own "version" property or attribute for node 
types in TOSCA 1.0.

On Fri, Aug 4, 2017 at 7:05 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi,
>
> The TOSCA spec mentions about the version as a keyname for different 
> type definitions(Node, Group, Interface, Artifacts, Data .. .) As 
> mentioned in spec this is for the re-use of different types . Does 
> ARIA support the version at this stage ? What is the scope of 
> orchestrator when it comes to the version support ?
>
>
>
> Regards,
> DJ
>

Version support for different TOSCA types

[D Jayachandran]

Hi,

The TOSCA spec mentions about the version as a keyname for different type 
definitions(Node, Group, Interface, Artifacts, Data .. .)
As mentioned in spec this is for the re-use of different types . Does ARIA 
support the version at this stage ? What is the scope of orchestrator when it 
comes to the version support ?



Regards,
DJ

RE: Inputs and Node object context for python and shell scripts

[D Jayachandran]

Am resending this to be on the same thread.

Do we also need to consider wrapping the artifacts model in the node object 
context being received by the plugin method ?
The artifacts can be used by the plugins during execution right ?


Regards,
DJ

-Original Message-
From: Maxim Orlov [mailto:ma...@cloudify.co] 
Sent: Thursday, August 03, 2017 1:32 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Inputs and Node object context for python and shell scripts

You're right, attributes and properties are similar in their nature. You do not 
need to worry yourself with the model behind them.
On the other hand relationship, capabilities etc... are more complex data 
structures, and thus they remain structured as a model.

On Wed, Aug 2, 2017 at 9:56 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Max,
>
> Thanks for the info.  So with this decorator we get only the 
> attributes and properties wrapped as dictionary.
> All other node objects like relationships, capabilities and interfaces 
> are as wrapped mapped collections.
>
> Regards,
> DJ
> -Original Message-
> From: Maxim Orlov [mailto:ma...@cloudify.co]
> Sent: Tuesday, August 01, 2017 4:24 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Inputs and Node object context for python and shell 
> scripts
>
> Sorry for the broken email, it seems my markup translator has some 
> funky behavior. The code block is:
>
> from aria import operation
>
> @operation
> def samplemethod(ctx=None, **inputs):
>   print "ctx -->",ctx
>   print "inputs -->",inputs
>   ctx.node.attributes['test'] = "abc"
>
>
> On Tue, Aug 1, 2017 at 1:48 PM Maxim Orlov <ma...@cloudify.co> wrote:
>
> > Oh, i see. For each method which represents an operation, you should 
> > use the @operation decorator. Thus samplemethod would look like this:
> >
> > from aria import operation
> > @operation
> >
> > def samplemethod(ctx=None, **inputs):
> > print "ctx -->",ctx
> > print "inputs -->",inputs
> > ctx.node.attributes['test'] = "abc"
> >
> > It is actually this decorator which wraps the attribute model for you.
> >
> > p.s.
> > the ctx comes with its own logger, thus using ctx.logger.info("ctx 
> > -->
> > {0}".format(ctx)) instead of print "ctx -->", ctx. This will persist 
> > your logs, and in case of remote execution, print your logs to the 
> > local terminal.
> > ​
> >
> > On Tue, Aug 1, 2017 at 11:30 AM D Jayachandran < 
> > d.jayachand...@ericsson.com> wrote:
> >
> >> Hi Max,
> >>
> >> I have a service template with just node templates web_app and 
> >> database with a depends on Relationship. Both use the same custom 
> >> node type derived from "tosca:Root".
> >> I just have the create operation defined where the implementation 
> >> points to a plugin module. Am trying to set the attribute value in 
> >> the
> plugin.
> >> Please find below service template and node types
> >>
> >> SERVICE TEMPLATE
> >>
> >> tosca_definitions_version: tosca_simple_yaml_1_0
> >>
> >> imports:
> >>   - types/kubernetes_type.yaml
> >>   - aria-1.0
> >>
> >> topology_template:
> >>
> >> inputs:
> >> web_app_name:
> >> type: string
> >> value: tosca-webapp
> >>
> >> web_app_image:
> >> type: string
> >> value: kuber-master:5000/webwithdbinput
> >>
> >> web_app_port:
> >> type: integer
> >> value: 80
> >>
> >> db_name:
> >> type: string
> >> value: tosca-database
> >>
> >> db_image:
> >> type: string
> >> value: kuber-master:5000/dbforweb
> >>
> >> db_port:
> >> type: integer
> >> value: 3306
> >>
> >>
> >> policies:
> >>   testplugin:
> >> type: aria.Plugin
> >> description: policy_description
> >> properties:
> >> version: 1.2.0
> >> enabled: true
> >>
> >> node_templates:
> >> web_app:
> >> type: nodes.Container.Application.Kubernetes
> >> properties:
> >>  

RE: pip executable expected as part of plugin install.

[D Jayachandran]

Thanks Avia, I will open an issue.

Regards,
DJ

-Original Message-
From: Avia Efrat [mailto:a...@cloudify.co] 
Sent: Thursday, August 03, 2017 4:01 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: pip executable expected as part of plugin install.

Hi DJ,
It seems you are correct, I don't see a reason for not using the pip library.
Maybe it was that way since we didn't want to add pip as a dependency 
explicitly (this code is from the beginning of ARIA).

Feel free to open an issue about that =)

On Wed, Aug 2, 2017 at 10:19 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> Am using a Ubuntu version of linux for my development and ARIA does 
> not find the correct path of pip during the plugin install.
> To be precise this happens when pip freeze is executed.
>
> @staticmethod
> def _pip_freeze():
> """Run pip freeze in current environment and return the output"""
> bin_dir = 'Scripts' if os.name == 'nt' else 'bin'
> pip_path = os.path.join(sys.prefix, bin_dir,
> 'pip{0}'.format('.exe' if os.name == 'nt'
> else ''))
> pip_freeze = subprocess.Popen([pip_path, 'freeze'],
> stdout=subprocess.PIPE)
> pip_freeze_output, _ = pip_freeze.communicate()
> assert not pip_freeze.poll()
> return pip_freeze_output
>
> Now the question is why are we executing a pip command directly and 
> not using pip as a library.
>
>
> Regards,
> DJ
>

RE: Inputs and Node object context for python and shell scripts

[D Jayachandran]

Hi Max,

Do we also need to consider wrapping the artifacts model in the node object 
context being received by the plugin method ?
The artifacts can be used the plugins during execution.


Regards,
DJ
-Original Message-
From: D Jayachandran 
Sent: Wednesday, August 02, 2017 12:26 PM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Inputs and Node object context for python and shell scripts

Hi Max,

Thanks for the info.  So with this decorator we get only the attributes and 
properties wrapped as dictionary. 
All other node objects like relationships, capabilities and interfaces are as 
wrapped mapped collections.

Regards,
DJ
-Original Message-
From: Maxim Orlov [mailto:ma...@cloudify.co]
Sent: Tuesday, August 01, 2017 4:24 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Inputs and Node object context for python and shell scripts

Sorry for the broken email, it seems my markup translator has some funky 
behavior. The code block is:

from aria import operation

@operation
def samplemethod(ctx=None, **inputs):
  print "ctx -->",ctx
  print "inputs -->",inputs
  ctx.node.attributes['test'] = "abc"


On Tue, Aug 1, 2017 at 1:48 PM Maxim Orlov <ma...@cloudify.co> wrote:

> Oh, i see. For each method which represents an operation, you should 
> use the @operation decorator. Thus samplemethod would look like this:
>
> from aria import operation
> @operation
>
> def samplemethod(ctx=None, **inputs):
> print "ctx -->",ctx
> print "inputs -->",inputs
> ctx.node.attributes['test'] = "abc"
>
> It is actually this decorator which wraps the attribute model for you.
>
> p.s.
> the ctx comes with its own logger, thus using ctx.logger.info("ctx -->
> {0}".format(ctx)) instead of print "ctx -->", ctx. This will persist 
> your logs, and in case of remote execution, print your logs to the 
> local terminal.
> ​
>
> On Tue, Aug 1, 2017 at 11:30 AM D Jayachandran < 
> d.jayachand...@ericsson.com> wrote:
>
>> Hi Max,
>>
>> I have a service template with just node templates web_app and 
>> database with a depends on Relationship. Both use the same custom 
>> node type derived from "tosca:Root".
>> I just have the create operation defined where the implementation 
>> points to a plugin module. Am trying to set the attribute value in the 
>> plugin.
>> Please find below service template and node types
>>
>> SERVICE TEMPLATE
>>
>> tosca_definitions_version: tosca_simple_yaml_1_0
>>
>> imports:
>>   - types/kubernetes_type.yaml
>>   - aria-1.0
>>
>> topology_template:
>>
>> inputs:
>> web_app_name:
>> type: string
>> value: tosca-webapp
>>
>> web_app_image:
>> type: string
>> value: kuber-master:5000/webwithdbinput
>>
>> web_app_port:
>> type: integer
>> value: 80
>>
>> db_name:
>> type: string
>> value: tosca-database
>>
>> db_image:
>> type: string
>> value: kuber-master:5000/dbforweb
>>
>> db_port:
>> type: integer
>> value: 3306
>>
>>
>> policies:
>>   testplugin:
>> type: aria.Plugin
>> description: policy_description
>> properties:
>> version: 1.2.0
>> enabled: true
>>
>> node_templates:
>> web_app:
>> type: nodes.Container.Application.Kubernetes
>> properties:
>> name: { get_input: web_app_name }
>> image: { get_input: web_app_image }
>> port: { get_input: web_app_port }
>> attributes:
>> test: abc
>> requirements:
>> - dependency:
>>   node: database
>>   relationship:
>>   type: tosca.relationships.DependsOn
>> interfaces:
>> Standard:
>> inputs:
>> name: { get_property: [ web_app, name] }
>> image: { get_property: [ web_app, image] }
>> exposed_port: { get_property: [ web_app, port] }
>> target_host: { get_property: [ database, name] }
>> target_port: { get_property: [ database, port] }
>> isService:

pip executable expected as part of plugin install.

[D Jayachandran]

Hi,

Am using a Ubuntu version of linux for my development and ARIA does not find 
the correct path of pip during the plugin install.
To be precise this happens when pip freeze is executed.

@staticmethod
def _pip_freeze():
"""Run pip freeze in current environment and return the output"""
bin_dir = 'Scripts' if os.name == 'nt' else 'bin'
pip_path = os.path.join(sys.prefix, bin_dir,
'pip{0}'.format('.exe' if os.name == 'nt' else 
''))
pip_freeze = subprocess.Popen([pip_path, 'freeze'], 
stdout=subprocess.PIPE)
pip_freeze_output, _ = pip_freeze.communicate()
assert not pip_freeze.poll()
return pip_freeze_output

Now the question is why are we executing a pip command directly and not using 
pip as a library.


Regards,
DJ

RE: Inputs and Node object context for python and shell scripts

[D Jayachandran]

Hi Max,

Thanks for the info.  So with this decorator we get only the attributes and 
properties wrapped as dictionary. 
All other node objects like relationships, capabilities and interfaces are as 
wrapped mapped collections.

Regards,
DJ
-Original Message-
From: Maxim Orlov [mailto:ma...@cloudify.co] 
Sent: Tuesday, August 01, 2017 4:24 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Inputs and Node object context for python and shell scripts

Sorry for the broken email, it seems my markup translator has some funky 
behavior. The code block is:

from aria import operation

@operation
def samplemethod(ctx=None, **inputs):
  print "ctx -->",ctx
  print "inputs -->",inputs
  ctx.node.attributes['test'] = "abc"


On Tue, Aug 1, 2017 at 1:48 PM Maxim Orlov <ma...@cloudify.co> wrote:

> Oh, i see. For each method which represents an operation, you should 
> use the @operation decorator. Thus samplemethod would look like this:
>
> from aria import operation
> @operation
>
> def samplemethod(ctx=None, **inputs):
> print "ctx -->",ctx
> print "inputs -->",inputs
> ctx.node.attributes['test'] = "abc"
>
> It is actually this decorator which wraps the attribute model for you.
>
> p.s.
> the ctx comes with its own logger, thus using ctx.logger.info("ctx -->
> {0}".format(ctx)) instead of print "ctx -->", ctx. This will persist 
> your logs, and in case of remote execution, print your logs to the 
> local terminal.
> ​
>
> On Tue, Aug 1, 2017 at 11:30 AM D Jayachandran < 
> d.jayachand...@ericsson.com> wrote:
>
>> Hi Max,
>>
>> I have a service template with just node templates web_app and 
>> database with a depends on Relationship. Both use the same custom 
>> node type derived from "tosca:Root".
>> I just have the create operation defined where the implementation 
>> points to a plugin module. Am trying to set the attribute value in the 
>> plugin.
>> Please find below service template and node types
>>
>> SERVICE TEMPLATE
>>
>> tosca_definitions_version: tosca_simple_yaml_1_0
>>
>> imports:
>>   - types/kubernetes_type.yaml
>>   - aria-1.0
>>
>> topology_template:
>>
>> inputs:
>> web_app_name:
>> type: string
>> value: tosca-webapp
>>
>> web_app_image:
>> type: string
>> value: kuber-master:5000/webwithdbinput
>>
>> web_app_port:
>> type: integer
>> value: 80
>>
>> db_name:
>> type: string
>> value: tosca-database
>>
>> db_image:
>> type: string
>> value: kuber-master:5000/dbforweb
>>
>> db_port:
>> type: integer
>> value: 3306
>>
>>
>> policies:
>>   testplugin:
>> type: aria.Plugin
>> description: policy_description
>> properties:
>> version: 1.2.0
>> enabled: true
>>
>> node_templates:
>> web_app:
>> type: nodes.Container.Application.Kubernetes
>> properties:
>> name: { get_input: web_app_name }
>> image: { get_input: web_app_image }
>> port: { get_input: web_app_port }
>> attributes:
>> test: abc
>> requirements:
>> - dependency:
>>   node: database
>>   relationship:
>>   type: tosca.relationships.DependsOn
>> interfaces:
>> Standard:
>> inputs:
>> name: { get_property: [ web_app, name] }
>> image: { get_property: [ web_app, image] }
>> exposed_port: { get_property: [ web_app, port] }
>> target_host: { get_property: [ database, name] }
>> target_port: { get_property: [ database, port] }
>> isService: true
>> create:
>> inputs:
>> name: { get_property: [ web_app, name] }
>> image: { get_property: [ web_app, image] }
>> exposed_port: { get_property: [ web_app, 
>> port] }
>> target_host: { get_pro

RE: Inputs and Node object context for python and shell scripts

[D Jayachandran]

 isService:
type: boolean
required: false
create:
implementation: 
primary: testplugin > sample.samplemethod


PLUGIN

def main():
"""Entry point for the application script"""
print("Call your main application code here")

def samplemethod(ctx=None, **inputs):
print "ctx -->",ctx
print "inputs -->",inputs
ctx.node.attributes['test'] = "abc"



Regards,
DJ



-Original Message-
From: Maxim Orlov [mailto:ma...@cloudify.co] 
Sent: Monday, July 31, 2017 10:22 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Inputs and Node object context for python and shell scripts

Interesting, can you describe exactly the scenario? including the service 
template and the operation you are trying to run

On Mon, Jul 31, 2017 at 6:12 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> I got the below error when I tried assigning values as like a dict.  
> It seems to fail when it tries to remove the existing value and 
> triggering a change event.
>
> ObjectDereferencedError: Can't emit change event for attribute 
> 'Node.attributes' - parent object of type  has been garbage 
> collected
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Maxim Orlov [mailto:ma...@cloudify.co]
> Sent: Monday, July 31, 2017 6:08 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Inputs and Node object context for python and shell 
> scripts
>
> From within any operation or workflow you don't need to use the ".value"
> notation. In order to access the attribute use 
> ctx.node.attributes['test'], and in order to assign the attribute just 
> use ctx.node.attributes['test'] = "abc". Using this (hopefully 
> simplified) notation does all the model related operations for you.
>
> On Mon, Jul 31, 2017, 15:02 D Jayachandran 
> <d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Max,
> >
> > Adding to this , I can access the attributes in my plugin only as 
> > below. ( I have defined the attribute test in my node type )
> >
> > ctx.node.attributes['test'].value
> >
> > And to update the value
> >
> > ctx.node.attributes['test'].value = "abc"
> >
> > But this does not update the db. Am I missing something here 
> > in-terms of the context usage ?
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Maxim Orlov [mailto:ma...@cloudify.co]
> > Sent: Sunday, July 30, 2017 7:37 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Inputs and Node object context for python and shell 
> > scripts
> >
> > Sorry it took me so long to check it out, things have been kind of
> hectic.
> > Anyway, there is a JIRA issue opened just for that:
> > https://issues.apache.org/jira/browse/ARIA-263.
> >
> > On Tue, Jul 25, 2017 at 9:23 PM, Maxim Orlov <ma...@cloudify.co> wrote:
> >
> > > Not entirely sure about that actually, let me double check that.
> > >
> > > On Tue, Jul 25, 2017 at 7:37 PM, Tal Liron <t...@cloudify.co> wrote:
> > >
> > >> It should be impossible in TOSCA to create an attribute that was 
> > >> not declared at the type. Are we allowing users to create any ad 
> > >> hoc attribute?
> > >>
> > >> On Tue, Jul 25, 2017 at 7:33 AM, Maxim Orlov <ma...@cloudify.co>
> wrote:
> > >>
> > >> > Indeed runtime_properties became attributes in ARIA . As for 
> > >> > the
> > >> behavior,
> > >> > attributes behave just as a dict would (behind the scenes 
> > >> > attributes translate to a proper Attribute TOSCA model).
> > >> > No need to define the attributes on the node-type level, if an 
> > >> > attribute with that name exists in on the model, the value of 
> > >> > that attribute
> > >> would be
> > >> > overridden, if you are creating a whole new attribute, a proper
> > >> Attribute
> > >> > model would be created for you.
> > >> >
> > >> > as for:
> > >> >
> > >> > ctx.node.attributes['map']['key'] = 'value'
> > >> >
> > >> > “map” is a name of an attribute which holds a dict, “key” is a 
> > >> > key in
> > >> that
> > >> > dict.
> > >> > ​
> > >> >
> > >> > On Tue, Jul 25, 2017 at 3:07 PM, D Jaya

RE: Inputs and Node object context for python and shell scripts

[D Jayachandran]

Hi,

I got the below error when I tried assigning values as like a dict.  It seems 
to fail when it tries to remove the existing value and triggering a change 
event.

ObjectDereferencedError: Can't emit change event for attribute 
'Node.attributes' - parent object of type  has been garbage collected


Regards,
DJ

-Original Message-
From: Maxim Orlov [mailto:ma...@cloudify.co] 
Sent: Monday, July 31, 2017 6:08 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Inputs and Node object context for python and shell scripts

From within any operation or workflow you don't need to use the ".value"
notation. In order to access the attribute use ctx.node.attributes['test'], and 
in order to assign the attribute just use ctx.node.attributes['test'] = "abc". 
Using this (hopefully simplified) notation does all the model related 
operations for you.

On Mon, Jul 31, 2017, 15:02 D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Max,
>
> Adding to this , I can access the attributes in my plugin only as 
> below. ( I have defined the attribute test in my node type )
>
> ctx.node.attributes['test'].value
>
> And to update the value
>
> ctx.node.attributes['test'].value = "abc"
>
> But this does not update the db. Am I missing something here in-terms 
> of the context usage ?
>
>
> Regards,
> DJ
> -Original Message-
> From: Maxim Orlov [mailto:ma...@cloudify.co]
> Sent: Sunday, July 30, 2017 7:37 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Inputs and Node object context for python and shell 
> scripts
>
> Sorry it took me so long to check it out, things have been kind of hectic.
> Anyway, there is a JIRA issue opened just for that:
> https://issues.apache.org/jira/browse/ARIA-263.
>
> On Tue, Jul 25, 2017 at 9:23 PM, Maxim Orlov <ma...@cloudify.co> wrote:
>
> > Not entirely sure about that actually, let me double check that.
> >
> > On Tue, Jul 25, 2017 at 7:37 PM, Tal Liron <t...@cloudify.co> wrote:
> >
> >> It should be impossible in TOSCA to create an attribute that was 
> >> not declared at the type. Are we allowing users to create any ad 
> >> hoc attribute?
> >>
> >> On Tue, Jul 25, 2017 at 7:33 AM, Maxim Orlov <ma...@cloudify.co> wrote:
> >>
> >> > Indeed runtime_properties became attributes in ARIA . As for the
> >> behavior,
> >> > attributes behave just as a dict would (behind the scenes 
> >> > attributes translate to a proper Attribute TOSCA model).
> >> > No need to define the attributes on the node-type level, if an 
> >> > attribute with that name exists in on the model, the value of 
> >> > that attribute
> >> would be
> >> > overridden, if you are creating a whole new attribute, a proper
> >> Attribute
> >> > model would be created for you.
> >> >
> >> > as for:
> >> >
> >> > ctx.node.attributes['map']['key'] = 'value'
> >> >
> >> > “map” is a name of an attribute which holds a dict, “key” is a 
> >> > key in
> >> that
> >> > dict.
> >> > ​
> >> >
> >> > On Tue, Jul 25, 2017 at 3:07 PM, D Jayachandran < 
> >> > d.jayachand...@ericsson.com
> >> > > wrote:
> >> >
> >> > > Hi Max,
> >> > >
> >> > > I see the runtime_properties have been replaced with "attributes"
> >> > > and there has been multiple changes with respect to attribute
> handling.
> >> > >
> >> > > What do you refer by "map" in your below example, Is that a 
> >> > > keyword
> ?
> >> > > "ctx.node.attributes['map']['key'] = value"
> >> > >
> >> > > Also with runtime_properties plugins were able to update the 
> >> > > database
> >> > with
> >> > > new key=value. Can we achieve the same with attributes ?
> >> > > Do we need to define the attributes in the node-types to be 
> >> > > able to
> >> > update
> >> > > them by the plugins ?
> >> > >
> >> > > Regards,
> >> > > DJ
> >> > >
> >> > > -Original Message-
> >> > > From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> >> > > Sent: Tuesday, July 25, 2017 11:23 AM
> >> > > To: dev@ariatosca.incubator.apache.org
> >> > > Subject: RE: Inputs and Node object context for python and 
> >&g

RE: Inputs and Node object context for python and shell scripts

[D Jayachandran]

Hi Max,

Adding to this , I can access the attributes in my plugin only as below. ( I 
have defined the attribute test in my node type )

ctx.node.attributes['test'].value

And to update the value 

ctx.node.attributes['test'].value = "abc"

But this does not update the db. Am I missing something here in-terms of the 
context usage ?


Regards,
DJ
-Original Message-
From: Maxim Orlov [mailto:ma...@cloudify.co] 
Sent: Sunday, July 30, 2017 7:37 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Inputs and Node object context for python and shell scripts

Sorry it took me so long to check it out, things have been kind of hectic.
Anyway, there is a JIRA issue opened just for that:
https://issues.apache.org/jira/browse/ARIA-263.

On Tue, Jul 25, 2017 at 9:23 PM, Maxim Orlov <ma...@cloudify.co> wrote:

> Not entirely sure about that actually, let me double check that.
>
> On Tue, Jul 25, 2017 at 7:37 PM, Tal Liron <t...@cloudify.co> wrote:
>
>> It should be impossible in TOSCA to create an attribute that was not 
>> declared at the type. Are we allowing users to create any ad hoc 
>> attribute?
>>
>> On Tue, Jul 25, 2017 at 7:33 AM, Maxim Orlov <ma...@cloudify.co> wrote:
>>
>> > Indeed runtime_properties became attributes in ARIA . As for the
>> behavior,
>> > attributes behave just as a dict would (behind the scenes 
>> > attributes translate to a proper Attribute TOSCA model).
>> > No need to define the attributes on the node-type level, if an 
>> > attribute with that name exists in on the model, the value of that 
>> > attribute
>> would be
>> > overridden, if you are creating a whole new attribute, a proper
>> Attribute
>> > model would be created for you.
>> >
>> > as for:
>> >
>> > ctx.node.attributes['map']['key'] = 'value'
>> >
>> > “map” is a name of an attribute which holds a dict, “key” is a key 
>> > in
>> that
>> > dict.
>> > ​
>> >
>> > On Tue, Jul 25, 2017 at 3:07 PM, D Jayachandran < 
>> > d.jayachand...@ericsson.com
>> > > wrote:
>> >
>> > > Hi Max,
>> > >
>> > > I see the runtime_properties have been replaced with "attributes" 
>> > > and there has been multiple changes with respect to attribute handling.
>> > >
>> > > What do you refer by "map" in your below example, Is that a keyword ?
>> > > "ctx.node.attributes['map']['key'] = value"
>> > >
>> > > Also with runtime_properties plugins were able to update the 
>> > > database
>> > with
>> > > new key=value. Can we achieve the same with attributes ?
>> > > Do we need to define the attributes in the node-types to be able 
>> > > to
>> > update
>> > > them by the plugins ?
>> > >
>> > > Regards,
>> > > DJ
>> > >
>> > > -Original Message-
>> > > From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
>> > > Sent: Tuesday, July 25, 2017 11:23 AM
>> > > To: dev@ariatosca.incubator.apache.org
>> > > Subject: RE: Inputs and Node object context for python and shell
>> scripts
>> > >
>> > > Hi Max,
>> > >
>> > > Yes I can access the context ctx with a python plugin and shell
>> script as
>> > > you have mentioned.
>> > > But with python script .py files under implementation, am not 
>> > > sure if
>> the
>> > > ctx and inputs are passed as "globals". I will re-confirm this.
>> > > The inputs which I was referring here were the lifecycle 
>> > > operation
>> > inputs.
>> > >
>> > >
>> > > Regards,
>> > > DJ
>> > >
>> > > -Original Message-
>> > > From: Maxim Orlov [mailto:ma...@gigaspaces.com]
>> > > Sent: Tuesday, July 25, 2017 12:14 AM
>> > > To: dev@ariatosca.incubator.apache.org
>> > > Subject: Re: Inputs and Node object context for python and shell
>> scripts
>> > >
>> > > I'm not entirely sure to which inputs you are referring to, but 
>> > > any
>> ctx
>> > > attribute or method accessible from a python script is accessible 
>> > > form
>> > any
>> > > shell script. For example:
>> > >
>> > >- "ctx.node.attributes['map']['key']" (in python) is "ctx node
>> > >attributes map.k

RE: Openstack plugin

[D Jayachandran]

Hi Max,

IF I understand correctly, 
we need to take the cloudify openstack plugin and replace the 
plugin.yaml with the one found in the repo.
Install this updated plugin with ARIA
Install the adapter found in this repo to make use of the plugin

Am I right with my understanding ?  Also why this adapter is not included with 
ARIA by default ?


Regards,
DJ
-Original Message-
From: Maxim Orlov [mailto:ma...@gigaspaces.com] 
Sent: Monday, July 24, 2017 9:17 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Openstack plugin

Hey DJ,

Basically ARIA indeed has an adapter for cloudify-based plugins. This enables 
support for any cloudify plugins (Provided the plugin.yaml has been translated 
into TOSCA). Note that later on, ARIA will have native plugins and will not 
rely on kindness of Cloudify.
You can find the Cloudify repo here
<https://github.com/cloudify-cosmo/aria-extension-cloudify>. It holds some 
examples, the plugin.yaml and the adapter itself.

On Mon, Jul 24, 2017 at 2:01 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Thanks for the information Tal.  What is the adapter which you are 
> referring here ?
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@gigaspaces.com]
> Sent: Friday, July 21, 2017 8:37 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Openstack plugin
>
> ARIA has an adapter that can use Cloudify plugins, and it has been 
> tested successfully with both OpenStack and AWS so far.
>
> Unfortunately there are no instructions on how to use it. I know just 
> the right person to write it and will ask him to do so. :)
>
> On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > Will openstack plugin be available as part of any ARIA release ?
> > Is this already been looked upon or in the backlog ?
> >
> >
> > Regards,
> > DJ
> >
>

RE: Inputs and Node object context for python and shell scripts

[D Jayachandran]

Hi Max,

I see the runtime_properties have been replaced with "attributes" and there has 
been multiple changes with respect to attribute handling.

What do you refer by "map" in your below example, Is that a keyword ?
"ctx.node.attributes['map']['key'] = value"
 
Also with runtime_properties plugins were able to update the database with new 
key=value. Can we achieve the same with attributes ?
Do we need to define the attributes in the node-types to be able to update them 
by the plugins ?

Regards,
DJ

-----Original Message-
From: D Jayachandran [mailto:d.jayachand...@ericsson.com] 
Sent: Tuesday, July 25, 2017 11:23 AM
To: dev@ariatosca.incubator.apache.org
Subject: RE: Inputs and Node object context for python and shell scripts

Hi Max,

Yes I can access the context ctx with a python plugin and shell script as you 
have mentioned.
But with python script .py files under implementation, am not sure if the ctx 
and inputs are passed as "globals". I will re-confirm this.
The inputs which I was referring here were the lifecycle operation inputs.


Regards,
DJ

-Original Message-
From: Maxim Orlov [mailto:ma...@gigaspaces.com]
Sent: Tuesday, July 25, 2017 12:14 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Inputs and Node object context for python and shell scripts

I'm not entirely sure to which inputs you are referring to, but any ctx 
attribute or method accessible from a python script is accessible form any 
shell script. For example:

   - "ctx.node.attributes['map']['key']" (in python) is "ctx node
   attributes map.key" (under bash)
   - "ctx.node.attributes['map']['key'] = value" (in python) is "ctx node
   attributes map.key value" (under bash)
   - "ctx.logger.info('some message')" (in python) is "ctx logger info
   'some message'" (under bash)


On Mon, Jul 24, 2017 at 8:47 PM, Tal Liron <t...@gigaspaces.com> wrote:

> I'm pretty sure you can access the inputs via the ctx call. Can anyone 
> confirm how to do this?
>
> We really need to document ctx usage...
>
> On Mon, Jul 24, 2017 at 5:57 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > With current ARIA implementation, the python and shell scripts are 
> > being executed by the "execution plugin".
> >
> > The context object and inputs are not passed to passed to python scripts.
> > We would like this to be passed to the python scripts.
> > For shell scripts atleast the inputs needs to be passed. The context 
> > object can be accessed via client.py with the SOCKET URL.
> > Kindly let us know if this can be added as a JIRA issue ?
> >
> >
> > Regards,
> > DJ
> >
> >
> >
> >
>

RE: Inputs and Node object context for python and shell scripts

[D Jayachandran]

Hi Max,

Yes I can access the context ctx with a python plugin and shell script as you 
have mentioned.
But with python script .py files under implementation, am not sure if the ctx 
and inputs are passed as "globals". I will re-confirm this.
The inputs which I was referring here were the lifecycle operation inputs.


Regards,
DJ

-Original Message-
From: Maxim Orlov [mailto:ma...@gigaspaces.com] 
Sent: Tuesday, July 25, 2017 12:14 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Inputs and Node object context for python and shell scripts

I'm not entirely sure to which inputs you are referring to, but any ctx 
attribute or method accessible from a python script is accessible form any 
shell script. For example:

   - "ctx.node.attributes['map']['key']" (in python) is "ctx node
   attributes map.key" (under bash)
   - "ctx.node.attributes['map']['key'] = value" (in python) is "ctx node
   attributes map.key value" (under bash)
   - "ctx.logger.info('some message')" (in python) is "ctx logger info
   'some message'" (under bash)


On Mon, Jul 24, 2017 at 8:47 PM, Tal Liron <t...@gigaspaces.com> wrote:

> I'm pretty sure you can access the inputs via the ctx call. Can anyone 
> confirm how to do this?
>
> We really need to document ctx usage...
>
> On Mon, Jul 24, 2017 at 5:57 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > With current ARIA implementation, the python and shell scripts are 
> > being executed by the "execution plugin".
> >
> > The context object and inputs are not passed to passed to python scripts.
> > We would like this to be passed to the python scripts.
> > For shell scripts atleast the inputs needs to be passed. The context 
> > object can be accessed via client.py with the SOCKET URL.
> > Kindly let us know if this can be added as a JIRA issue ?
> >
> >
> > Regards,
> > DJ
> >
> >
> >
> >
>

RE: Openstack plugin

[D Jayachandran]

Thanks for the information Tal.  What is the adapter which you are referring 
here ?

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@gigaspaces.com] 
Sent: Friday, July 21, 2017 8:37 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Openstack plugin

ARIA has an adapter that can use Cloudify plugins, and it has been tested 
successfully with both OpenStack and AWS so far.

Unfortunately there are no instructions on how to use it. I know just the right 
person to write it and will ask him to do so. :)

On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> Will openstack plugin be available as part of any ARIA release ?
> Is this already been looked upon or in the backlog ?
>
>
> Regards,
> DJ
>

Inputs and Node object context for python and shell scripts

[D Jayachandran]

Hi,

With current ARIA implementation, the python and shell scripts are being 
executed by the "execution plugin".

The context object and inputs are not passed to passed to python scripts. We 
would like this to be passed to the python scripts.
For shell scripts atleast the inputs needs to be passed. The context object can 
be accessed via client.py with the SOCKET URL.
Kindly let us know if this can be added as a JIRA issue ?


Regards,
DJ

Openstack plugin

[D Jayachandran]

Hi,

Will openstack plugin be available as part of any ARIA release ?
Is this already been looked upon or in the backlog ?


Regards,
DJ

RE: Contribution for https://issues.apache.org/jira/browse/ARIA-118

[D Jayachandran]

Thanks John, Ran had already shared this to me and I recently made a 
contribution from my side.

Regards,
DJ

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Thursday, July 20, 2017 6:37 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118

You'll probably also want to review
https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+to+ARIA

John

On Thu, Jul 20, 2017 at 9:05 AM D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Thanks Tal,
>
> I will be working on this.
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@gigaspaces.com]
> Sent: Thursday, July 20, 2017 6:24 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Contribution for
> https://issues.apache.org/jira/browse/ARIA-118
>
> It's unassigned, so I don't see why not!
>
> On Thu, Jul 20, 2017 at 7:41 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > Do you have any plans on working on this JIRA issue ?
> > https://issues.apache.org/jira/browse/ARIA-118
> > Can we contribute on this ?
> >
> >
> > Regards,
> > DJ
> >
>

RE: Contribution for https://issues.apache.org/jira/browse/ARIA-118

[D Jayachandran]

Thanks Tal,

I will be working on this.

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@gigaspaces.com] 
Sent: Thursday, July 20, 2017 6:24 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118

It's unassigned, so I don't see why not!

On Thu, Jul 20, 2017 at 7:41 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi,
>
> Do you have any plans on working on this JIRA issue ?
> https://issues.apache.org/jira/browse/ARIA-118
> Can we contribute on this ?
>
>
> Regards,
> DJ
>

Contribution for https://issues.apache.org/jira/browse/ARIA-118

[D Jayachandran]

Hi,

Do you have any plans on working on this JIRA issue ? 
https://issues.apache.org/jira/browse/ARIA-118
Can we contribute on this ?


Regards,
DJ

RE: Missing support for type qualified name

[D Jayachandran]

Hi Ran,

I had some issue with committing changes to this PR. I closed the PR and opened 
a new one. 
Now the CI tests and build jobs are successful. Kindly check and let me know if 
its fine.

Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Tuesday, July 11, 2017 2:07 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Missing support for type qualified name

Hi DJ,

You shouldn't create another PR - the current should simply update when you 
push your changes into the relevant branch in your fork (in this case, the 
master branch).

At the moment I see 4 commits on the PR, and it seems to still be broken.
If it hasn't updated yet, please update it.
If it is already updated, please have a look at the errors, or let me know if 
you need any help with debugging it :)

Ran

On Tue, Jul 11, 2017 at 10:53 AM, D Jayachandran < d.jayachand...@ericsson.com> 
wrote:

> Hi Ran,
>
> I fixed those issues. I have commited those with changes , am not sure 
> if I have to make another PR ?
> Could you please advice me here ?
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Friday, July 07, 2017 3:28 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Missing support for type qualified name
>
> Hi DJ,
>
> Thank you for creating this pull request.
> I've added you as a Contributor (role) on JIRA, so you can now be 
> assigned to ARIA issues. I've assigned you to ARIA-277 as well.
>
> Regarding the PR itself, it seems to be currently failing some CI tests.
> Please see these links:
> https://github.com/apache/incubator-ariatosca/pull/179
> https://travis-ci.org/apache/incubator-ariatosca/builds/
> 251017348?utm_source=github_status_medium=notification
> https://ci.appveyor.com/project/ApacheSoftwareFoundation/
> incubator-ariatosca/build/1.0.2410
>
>
> Let me know if you need any help trying to debug or figure out these 
> issues
> :)
>
> Ran
>
> On Sun, Jun 11, 2017 at 11:36 AM, Ran Ziv <r...@gigaspaces.com> wrote:
>
> > Thanks DJ.
> >
> > Note that in order for the project to be able to accept your pull 
> > request, you'd first have to sign up Apache's ICLA agreement.
> > See more here <https://www.apache.org/dev/new-committers-guide.html>.
> >
> > Ran
> >
> > On Fri, Jun 9, 2017 at 2:04 PM, D Jayachandran < 
> > d.jayachand...@ericsson.com> wrote:
> >
> >> Hi Ran/Tal,
> >>
> >> Thanks for the confirmation. I have created a JIRA issue
> >> https://issues.apache.org/jira/browse/ARIA-277
> >> We will let you know when we fork and make a pull request for this.
> >>
> >> Regards,
> >> DJ
> >> -Original Message-
> >> From: Tal Liron [mailto:t...@gigaspaces.com]
> >> Sent: Thursday, June 08, 2017 11:47 PM
> >> To: dev@ariatosca.incubator.apache.org
> >> Subject: Re: Missing support for type qualified name
> >>
> >> Thanks, DJ. This was on the list of things to do but we indeed 
> >> forgot to create a JIRA for it...
> >>
> >> On Thu, Jun 8, 2017 at 8:24 AM, Ran Ziv <r...@gigaspaces.com> wrote:
> >>
> >> > Hi DJ,
> >> >
> >> > Sounds good. Feel free to create a new JIRA yourself!  And thanks 
> >> > for posting on the dev list before creating this issue.
> >> > One small note, I'd personally think of this as a "story" rather 
> >> > than a "bug" - We don't yet claim to be 100% TOSCA complaint, and 
> >> > we're familiar with several other missing spec sections 
> >> > implementations at
> >> the moment.
> >> >
> >> > Let me know if you need any help.
> >> > Tal might have more to add on this (Type qualified name) as well.
> >> >
> >> > Thank you
> >> > Ran
> >> >
> >> >
> >> > On Wed, Jun 7, 2017 at 3:35 PM, D Jayachandran < 
> >> > d.jayachand...@ericsson.com>
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > TOSCA Simple Yaml 1.0 profile specification supports usage of 
> >> > > the following Namespace Alias
> >> > >
> >> > >   1.  Shorthand Name
> >> > >   2.  Type Qualified Name
> >> > >   3.  Type URI
> >> > >
> >> > > ARIA currently supports only "Shorthand Name" and "Type URI". 
> >> > > The support for "Type Qualified Name" is missing which is 
> >> &

Plugin validation

[D Jayachandran]

Hi,

With current implementation, the plugin validation in a service template 
happens during the service creation (instantiation of service model).
Will it be appropriate if we have this plugin validation happening during the 
service-template creation itself ?



Regards,
DJ

RE: Missing support for type qualified name

[D Jayachandran]

Hi Ran,

I fixed those issues. I have commited those with changes , am not sure if I 
have to make another PR ?
Could you please advice me here ?


Regards,
DJ

-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Friday, July 07, 2017 3:28 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Missing support for type qualified name

Hi DJ,

Thank you for creating this pull request.
I've added you as a Contributor (role) on JIRA, so you can now be assigned to 
ARIA issues. I've assigned you to ARIA-277 as well.

Regarding the PR itself, it seems to be currently failing some CI tests.
Please see these links:
https://github.com/apache/incubator-ariatosca/pull/179
https://travis-ci.org/apache/incubator-ariatosca/builds/251017348?utm_source=github_status_medium=notification
https://ci.appveyor.com/project/ApacheSoftwareFoundation/incubator-ariatosca/build/1.0.2410


Let me know if you need any help trying to debug or figure out these issues
:)

Ran

On Sun, Jun 11, 2017 at 11:36 AM, Ran Ziv <r...@gigaspaces.com> wrote:

> Thanks DJ.
>
> Note that in order for the project to be able to accept your pull 
> request, you'd first have to sign up Apache's ICLA agreement.
> See more here <https://www.apache.org/dev/new-committers-guide.html>.
>
> Ran
>
> On Fri, Jun 9, 2017 at 2:04 PM, D Jayachandran < 
> d.jayachand...@ericsson.com> wrote:
>
>> Hi Ran/Tal,
>>
>> Thanks for the confirmation. I have created a JIRA issue
>> https://issues.apache.org/jira/browse/ARIA-277
>> We will let you know when we fork and make a pull request for this.
>>
>> Regards,
>> DJ
>> -Original Message-
>> From: Tal Liron [mailto:t...@gigaspaces.com]
>> Sent: Thursday, June 08, 2017 11:47 PM
>> To: dev@ariatosca.incubator.apache.org
>> Subject: Re: Missing support for type qualified name
>>
>> Thanks, DJ. This was on the list of things to do but we indeed forgot 
>> to create a JIRA for it...
>>
>> On Thu, Jun 8, 2017 at 8:24 AM, Ran Ziv <r...@gigaspaces.com> wrote:
>>
>> > Hi DJ,
>> >
>> > Sounds good. Feel free to create a new JIRA yourself!  And thanks 
>> > for posting on the dev list before creating this issue.
>> > One small note, I'd personally think of this as a "story" rather 
>> > than a "bug" - We don't yet claim to be 100% TOSCA complaint, and 
>> > we're familiar with several other missing spec sections 
>> > implementations at
>> the moment.
>> >
>> > Let me know if you need any help.
>> > Tal might have more to add on this (Type qualified name) as well.
>> >
>> > Thank you
>> > Ran
>> >
>> >
>> > On Wed, Jun 7, 2017 at 3:35 PM, D Jayachandran < 
>> > d.jayachand...@ericsson.com>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > TOSCA Simple Yaml 1.0 profile specification supports usage of  
>> > > the following Namespace Alias
>> > >
>> > >   1.  Shorthand Name
>> > >   2.  Type Qualified Name
>> > >   3.  Type URI
>> > >
>> > > ARIA currently supports only "Shorthand Name" and "Type URI". The 
>> > > support for "Type Qualified Name" is missing which is required to 
>> > > adhere with the TOSCA Simple yaml 1.0 specifications. Could this 
>> > > be considered as bug
>> > and a
>> > > JIRA issue opened for this ?
>> > > We would like to start our contribution with this.
>> > >
>> > >
>> > > Regards,
>> > > DJ
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Tal Liron
>> Senior Engineer
>> t...@gigaspaces.com | +1 (773) 828-9339 Cloudify | 
>> http://getcloudify.org 
>> <http://getcloudify.org?utm_source=signaturesatori_mediu
>> m=email_campaign=general_signature>
>>
>> <https://twitter.com/CloudifySource>
>> <https://www.linkedin.com/groups/8467478>
>> <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
>> [image: Azure Webinar]
>> <http://getcloudify.org/webinars/Azure-plugin-for-cloudify-
>> webinar.html?utm_source=signaturesatori_medium=
>> email_campaign=general_signature>
>>
>
>

RE: Query on operation inputs

[D Jayachandran]

Hi Avia,

Thanks for the detailed explanation. Finally we have better clarity and are in 
the same page.

Regards,
DJ

-Original Message-
From: Avia Efrat [mailto:a...@gigaspaces.com] 
Sent: Tuesday, July 11, 2017 3:42 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Query on operation inputs

Here is the Jira issue:
https://issues.apache.org/jira/browse/ARIA-313

On Tue, Jul 11, 2017 at 12:44 AM, Ran Ziv <r...@gigaspaces.com> wrote:

> Avia, could you please create a JIRA issue for this?
>
>
> On Mon, Jul 10, 2017 at 5:12 PM, Avia Efrat <a...@gigaspaces.com> wrote:
>
> > Hello DJ,
> >
> > I ran the example you provided: https://github.com/djay8887/Ar 
> > ia-operationInputs [It should be noted that you can't just parse the 
> > service template kubernetes-deployment.yaml as is. I needed to 
> > create a folder named type and place kubernetes_type.yaml in there, 
> > as the import: section in your service templates contains `- 
> > *types*/kubernetes_type.yaml`]
> >
> > *Short answer:*
> > You are correct, the example should pass, and we will change the 
> > code accordingly.
> >
> > *Longer answer + explanations:*
> > I will separate my answer into three parts. I will repeat some of 
> > what
> was
> > said before me, but I think it will help clear the situation.
> > 1. The result of my run.
> > 2. Why do we currently get this error.
> > 3. Our revised understanding of the TOSCA spec regarding the 
> > required
> field
> > of node type operation inputs.
> >
> > *1.* *The result of my run:*
> > The commands I ran were:
> > aria plugins install sample-1.0.0-py27-none-any.wgn aria 
> > service-templates store kubernetes-deployment.yaml dj aria services 
> > create -t dj dj aria executions start -s dj install after running 
> > the last command I got:
> > Declared parameters "labels" have not been provided values
> >
> > *2.* *Why do we currently get this error:* First, let my just 
> > clarify, that this error has no relation whatsoever to the contents 
> > of the inputs section under topology_template.
> > We are dealing here only with the inputs section of an operation, 
> > which
> is
> > section 3.5.13 Operation Definition <https://goo.gl/g5bMtV>.
> > Currently, when we execute a workflow (aria executions start ...), 
> > we
> check
> > the inputs of each operation in the following manner (ignoring 
> > interface inputs for now):
> > we check that every input defined in the input section of the node
> template
> > operation, whether the input is required or not has a value, has a value.
> > This check is done in the merge_parameters_value function, inside 
> > aria/modelling/utils, so you can check the logic yourself.
> >
> > Anyway, these values can be supplied directly from the service 
> > template,
> or
> > in an indirect way via execution inputs, or programmatically when
> creating
> > workflow tasks. The latter method shouldn't concern us now, as we 
> > are dealing with the operation inputs that were provided in the 
> > inputs
> section
> > of the operation.
> >
> > So, in conclusion, we get this error since the labels input is not
> assigned
> > a value in the inputs section of the operation inside the node template.
> > This happens even if the input is defined as required: false in the
> inputs
> > section of the operation inside the node *type*.
> >
> > *3. **Our revised understanding of the TOSCA spec regarding the 
> > required field operation definition inputs:* After rechecking the 
> > spec, we feel that an operation input that has
> > required:
> > false  indeed allows it not to be defined in the corresponding 
> > operation
> in
> > the service template. We base this on section 3.5.13.1 Operation
> Definition
> > keyname <https://goo.gl/g5bMtV>. This section clearly state the node
> type
> > operation inputs are of type property definitions (3.5.8)
> > <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#
> > DEFN_ELEMENT_PROPERTY_DEFN>
> > .
> >
> > Therefore, the required field of a node type operation input is the 
> > same
> as
> > the required field in a node type property.
> >
> > So, just as you can omit in a node template property that has required:
> > false in its corresponding node type property, you can omit a node
> template
> > operation input that has required: false in its corresponding node 
> > type operation

RE: Missing support for type qualified name

[D Jayachandran]

Hi Ran,

I tried running the tests locally in my repository and there was no "Type 
error" as mentioned in the CI build.
But am getting some tests failed which am looking into. I will email if I need 
any help.


Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Friday, July 07, 2017 3:28 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Missing support for type qualified name

Hi DJ,

Thank you for creating this pull request.
I've added you as a Contributor (role) on JIRA, so you can now be assigned to 
ARIA issues. I've assigned you to ARIA-277 as well.

Regarding the PR itself, it seems to be currently failing some CI tests.
Please see these links:
https://github.com/apache/incubator-ariatosca/pull/179
https://travis-ci.org/apache/incubator-ariatosca/builds/251017348?utm_source=github_status_medium=notification
https://ci.appveyor.com/project/ApacheSoftwareFoundation/incubator-ariatosca/build/1.0.2410


Let me know if you need any help trying to debug or figure out these issues
:)

Ran

On Sun, Jun 11, 2017 at 11:36 AM, Ran Ziv <r...@gigaspaces.com> wrote:

> Thanks DJ.
>
> Note that in order for the project to be able to accept your pull 
> request, you'd first have to sign up Apache's ICLA agreement.
> See more here <https://www.apache.org/dev/new-committers-guide.html>.
>
> Ran
>
> On Fri, Jun 9, 2017 at 2:04 PM, D Jayachandran < 
> d.jayachand...@ericsson.com> wrote:
>
>> Hi Ran/Tal,
>>
>> Thanks for the confirmation. I have created a JIRA issue
>> https://issues.apache.org/jira/browse/ARIA-277
>> We will let you know when we fork and make a pull request for this.
>>
>> Regards,
>> DJ
>> -Original Message-
>> From: Tal Liron [mailto:t...@gigaspaces.com]
>> Sent: Thursday, June 08, 2017 11:47 PM
>> To: dev@ariatosca.incubator.apache.org
>> Subject: Re: Missing support for type qualified name
>>
>> Thanks, DJ. This was on the list of things to do but we indeed forgot 
>> to create a JIRA for it...
>>
>> On Thu, Jun 8, 2017 at 8:24 AM, Ran Ziv <r...@gigaspaces.com> wrote:
>>
>> > Hi DJ,
>> >
>> > Sounds good. Feel free to create a new JIRA yourself!  And thanks 
>> > for posting on the dev list before creating this issue.
>> > One small note, I'd personally think of this as a "story" rather 
>> > than a "bug" - We don't yet claim to be 100% TOSCA complaint, and 
>> > we're familiar with several other missing spec sections 
>> > implementations at
>> the moment.
>> >
>> > Let me know if you need any help.
>> > Tal might have more to add on this (Type qualified name) as well.
>> >
>> > Thank you
>> > Ran
>> >
>> >
>> > On Wed, Jun 7, 2017 at 3:35 PM, D Jayachandran < 
>> > d.jayachand...@ericsson.com>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > TOSCA Simple Yaml 1.0 profile specification supports usage of  
>> > > the following Namespace Alias
>> > >
>> > >   1.  Shorthand Name
>> > >   2.  Type Qualified Name
>> > >   3.  Type URI
>> > >
>> > > ARIA currently supports only "Shorthand Name" and "Type URI". The 
>> > > support for "Type Qualified Name" is missing which is required to 
>> > > adhere with the TOSCA Simple yaml 1.0 specifications. Could this 
>> > > be considered as bug
>> > and a
>> > > JIRA issue opened for this ?
>> > > We would like to start our contribution with this.
>> > >
>> > >
>> > > Regards,
>> > > DJ
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Tal Liron
>> Senior Engineer
>> t...@gigaspaces.com | +1 (773) 828-9339 Cloudify | 
>> http://getcloudify.org 
>> <http://getcloudify.org?utm_source=signaturesatori_mediu
>> m=email_campaign=general_signature>
>>
>> <https://twitter.com/CloudifySource>
>> <https://www.linkedin.com/groups/8467478>
>> <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
>> [image: Azure Webinar]
>> <http://getcloudify.org/webinars/Azure-plugin-for-cloudify-
>> webinar.html?utm_source=signaturesatori_medium=
>> email_campaign=general_signature>
>>
>
>

Inputs to a life cycle operation

[D Jayachandran]

Hi,

With the current ARIA implementation,


  *   Only the operation level inputs, (inputs under 
"create","configure","start","stop") are passed during a workflow execution.
  *   As per TOSCA spec Interface level inputs ( inputs under "Standard" 
Interface) can also be defined

With the above points, don't the interface level inputs also be passed for any 
operation Task ?
I think interface level inputs needs to be merged with operation level but the 
operation level inputs taking precedence.
Please let us know if the above understanding is correct and could be fixed in 
ARIA ?

Regards,
DJ

RE: Support for TOSCA Simple Profile NFV 1.0

[D Jayachandran]

Thanks for the information Avia.
I will check on that.

Regards,
DJ

-Original Message-
From: Avia Efrat [mailto:a...@gigaspaces.com] 
Sent: Tuesday, June 13, 2017 2:59 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Support for TOSCA Simple Profile NFV 1.0

Hi DJ,

Just updating that the pull request was merged.

Note that there are some inconsistencies in csd04, so if you have any questions 
regarding our reasoning in resolving them, feel encouraged to ask.

On Wed, Jun 7, 2017 at 10:09 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Thanks for the update Avia.
>
> Regards,
> DJ
>
> -Original Message-
> From: Avia Efrat [mailto:a...@gigaspaces.com]
> Sent: Wednesday, June 07, 2017 3:03 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Support for TOSCA Simple Profile NFV 1.0
>
> Hi DJ,
>
> I've created a pull request for the issue that Tal opened:
> https://github.com/apache/incubator-ariatosca/pull/147
> I expect it to be merged on Thursday/Friday.
>
> On Thu, Jun 1, 2017 at 7:02 PM, Tal Liron <t...@gigaspaces.com> wrote:
>
> > Thanks DJ, I opened a new JIRA issue for this if you want to track it:
> >
> > https://issues.apache.org/jira/browse/ARIA-275
> >
> > It shouldn't be too hard to do, just some busy work in YAML. Anyone 
> > on the mailing list want to tackle this?
> >
> > On Thu, Jun 1, 2017 at 4:53 AM, D Jayachandran < 
> > d.jayachand...@ericsson.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I hope ARIA currently supports , TOSCA Simple Profile NFV 1.0 draft 03.
> > > The Latest available TOSCA NFV profile is Simple profile NFV 1.0 
> > > draft
> > 04,
> > > released on 11 May 2017.
> > >
> > > Could you kindly confirm the current level of support from ARIA 
> > > for NFV profiles and do you have any timelines to support draft 04 ?
> > >
> > >
> > > Regards,
> > > DJ
> > >
> >
> >
> >
> > --
> > Tal Liron
> > Senior Engineer
> > t...@gigaspaces.com | +1 (773) 828-9339 Cloudify | 
> > http://getcloudify.org 
> > <http://getcloudify.org?utm_source=signaturesatori_
> > medium=email_campaign=general_signature>
> >
> > <https://twitter.com/CloudifySource>
> > <https://www.linkedin.com/groups/8467478>
> > <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo
> >
> > [image: Azure Webinar]
> > <http://getcloudify.org/webinars/Azure-plugin-for-
> > cloudify-webinar.html?utm_source=signaturesatori_
> > medium=email_campaign=general_signature>
> >
>
>
>
> --
> Avia Efrat
> SW Engineer
> a...@gigaspaces.com | +972546204553
> Cloudify | http://getcloudify.org
> <http://getcloudify.org?utm_source=signaturesatori_
> medium=email_campaign=general_signature>
>
> <https://twitter.com/CloudifySource>
> <https://www.linkedin.com/groups/8467478>
> <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
> [image: Azure Webinar]
> <http://getcloudify.org/webinars/Azure-plugin-for-
> cloudify-webinar.html?utm_source=signaturesatori_
> medium=email_campaign=general_signature>
>



--
Avia Efrat
SW Engineer
a...@gigaspaces.com | +972546204553
Cloudify | http://getcloudify.org
<http://getcloudify.org?utm_source=signaturesatori_medium=email_campaign=general_signature>

<https://twitter.com/CloudifySource>
<https://www.linkedin.com/groups/8467478>
<https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
[image: Azure Webinar]
<http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori_medium=email_campaign=general_signature>

RE: Missing support for type qualified name

[D Jayachandran]

Hi Ran/Tal,

Thanks for the confirmation. I have created a JIRA issue 
https://issues.apache.org/jira/browse/ARIA-277 
We will let you know when we fork and make a pull request for this.

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@gigaspaces.com] 
Sent: Thursday, June 08, 2017 11:47 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Missing support for type qualified name

Thanks, DJ. This was on the list of things to do but we indeed forgot to create 
a JIRA for it...

On Thu, Jun 8, 2017 at 8:24 AM, Ran Ziv <r...@gigaspaces.com> wrote:

> Hi DJ,
>
> Sounds good. Feel free to create a new JIRA yourself!  And thanks for 
> posting on the dev list before creating this issue.
> One small note, I'd personally think of this as a "story" rather than 
> a "bug" - We don't yet claim to be 100% TOSCA complaint, and we're 
> familiar with several other missing spec sections implementations at the 
> moment.
>
> Let me know if you need any help.
> Tal might have more to add on this (Type qualified name) as well.
>
> Thank you
> Ran
>
>
> On Wed, Jun 7, 2017 at 3:35 PM, D Jayachandran < 
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi,
> >
> > TOSCA Simple Yaml 1.0 profile specification supports usage of  the 
> > following Namespace Alias
> >
> >   1.  Shorthand Name
> >   2.  Type Qualified Name
> >   3.  Type URI
> >
> > ARIA currently supports only "Shorthand Name" and "Type URI". The 
> > support for "Type Qualified Name" is missing which is required to 
> > adhere with the TOSCA Simple yaml 1.0 specifications. Could this be 
> > considered as bug
> and a
> > JIRA issue opened for this ?
> > We would like to start our contribution with this.
> >
> >
> > Regards,
> > DJ
> >
> >
>



--
Tal Liron
Senior Engineer
t...@gigaspaces.com | +1 (773) 828-9339
Cloudify | http://getcloudify.org
<http://getcloudify.org?utm_source=signaturesatori_medium=email_campaign=general_signature>

<https://twitter.com/CloudifySource>
<https://www.linkedin.com/groups/8467478>
<https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
[image: Azure Webinar]
<http://getcloudify.org/webinars/Azure-plugin-for-cloudify-webinar.html?utm_source=signaturesatori_medium=email_campaign=general_signature>

Missing support for type qualified name

[D Jayachandran]

Hi,

TOSCA Simple Yaml 1.0 profile specification supports usage of  the following 
Namespace Alias

  1.  Shorthand Name
  2.  Type Qualified Name
  3.  Type URI

ARIA currently supports only "Shorthand Name" and "Type URI". The support for 
"Type Qualified Name" is missing which is required to adhere with the TOSCA 
Simple yaml 1.0 specifications. Could this be considered as bug and a JIRA 
issue opened for this ?
We would like to start our contribution with this.


Regards,
DJ

RE: Plugin structure and specifications

[D Jayachandran]

Hi Ran,

Thanks for the information. I do agree with you on having plugin.yaml as part 
of plugin and importing it to service template to have the plugin specific 
types.
Could you point me to some documentation involving these or any example of 
plugin.yaml


Regards,
DJ

-Original Message-
From: Ran Ziv [mailto:r...@gigaspaces.com] 
Sent: Tuesday, June 06, 2017 6:41 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Plugin structure and specifications

? Do we have any specifications on the structure of plugin ?

--> A plugin should simply be a standard Python package really; There 
--> are
no special constraints on its structure.
If the plugin has dependencies, they do need to be compatible with ARIA's, as 
the plugin's code will be loaded in the same environment as the ARIA code which 
loads it; However, one plugin's dependencies do not need to be compatible with 
another plugin's dependencies - those are completely isolated from one another 
thanks to the PluginManager class.
Also see this related jira issue
<https://issues.apache.org/jira/browse/ARIA-247>, which could be taken into 
consideration when deciding about the plugin's structure - although note that 
the notation/syntax used in the "implementation" field might change at some 
point to not be in "Python syntax".



? With the current state, a plugin can be referenced in different node types.
? Can a plugin also contain node types specific to its implementation ? If we 
can associate a plugin to specific node types there will not be need to import 
the node types in our service template every time.
We think bundling node types as part of plugin and having them available to 
those service templates using the plugins would be a good option. Do you have 
any suggestions regarding this ? Do you already have something on this in your 
roadmap ?

--> The plugin mechanism is a means of delivering code into ARIA. You 
--> can
have a "plugin.yaml" file to import manually from your service-template, where 
that file is coupled with operations (and a policy definition) of a specific 
plugin.
There is also a jira issue
<https://issues.apache.org/jira/browse/ARIA-118> about how this coupling might 
be made somewhat simpler.
However, I do not think that having the plugin "auto-import" the node type 
definitions is a good idea: First, it's not standard TOSCA - All yaml imports 
must be declared explicitly. Second, instead of being forced to declare the 
import, you'd be forced to declare the plugin policy (otherwise how would the 
parser know which "plugin.yaml" files to import for your service-template?
I think the case where the user simply defines a single import "openstack"
and automatically receives the ability to refer to types from the openstack 
plugin's "plugin.yaml" etc. is the way to go here.


Ran



On Tue, Jun 6, 2017 at 8:42 AM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi,
>
> ARIA currently supports plugin based lifecycle operation. A plugin 
> here refers to a python module packaged as a wagon archive.
> I have few queries on how the plugin is being seen at this moment
>
>
> ? Do we have any specifications on the structure of plugin ?
>
> ? With the current state, a plugin can be referenced in different node 
> types.
>
> ? Can a plugin also contain node types specific to its implementation 
> ? If we can associate a plugin to specific node types there will not 
> be need to import the node types in our service template every time.
>
> We think bundling node types as part of plugin and having them 
> available to those service templates using the plugins would be a good 
> option. Do you have any suggestions regarding this ? Do you already 
> have something on this in your roadmap ?
>
>
> Regards,
> DJ
>
>
>