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

[Thomas Nadeau]

Thanks. Ill take a look once the CI completes and merge if its cool.

--Tom


On Mon, Feb 12, 2018 at 9:58 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

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

[Tal Liron]

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

[Thomas Nadeau]

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

[Thomas Nadeau]

Got it.  Avia and Tal reviewed and it looked good. Will get merged soon.

—Tom


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

Re: ARIA-118 plugin.yaml importing

[Thomas Nadeau]

Nothing has changed for non-committers; use the canonical GitHub fork->push
patches->propose patch request method
on the same two GitHub repos:

https://github.com/apache/incubator-ariatosca-website

and

https://github.com/apache/incubator-ariatosca

I’ll be on slack from now too if you need additional help.

—Tom


On Dec 4, 2017, at 8:28 AM, D Jayachandran 
wrote:

Hi,

I need to contribute for this JIRA item. Previously I had made my
contribution by forking from the apache-ariatosca project.
Is the process changed now ? What is the process which I should follow now ?


Regards,
DJ

[GitHub] djay87 opened a new pull request #212: ARIA-118 plugin.yaml importing

[GitBox]

djay87 opened a new pull request #212: ARIA-118 plugin.yaml importing
URL: https://github.com/apache/incubator-ariatosca/pull/212
 
 
   This commit supports using the plugin.yaml present in a plugin wagon archive 
in a more simpler way as described below.
   
   imports:
 - file: -
   repository: plugins


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] asfgit commented on issue #212: ARIA-118 plugin.yaml importing

[GitBox]

asfgit commented on issue #212: ARIA-118 plugin.yaml importing
URL: 
https://github.com/apache/incubator-ariatosca/pull/212#issuecomment-348881562
 
 
   Can one of the admins verify this patch?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Updated] (ARIA-118) plugin.yaml importing

[Ran Ziv (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Ziv updated ARIA-118:
-
Description: 
Using a plugin currently requires a user first installs the plugin (using 
PluginManager), then import the relevant plugin.yaml file in the service 
template file. The import will currently likely point to a URL, or be a path 
relative to the service-template yaml file.

Some ideas for improvement and easing the import;
 - 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)
 - 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.
 - Perhaps ARIA should also support importing yaml files by using paths 
relative to the service-template's package root (as opposed to only looking for 
paths relative to the current yaml file)? Note that this could lead to 
ambiguities in some cases.


Note that the last two don't necessarily have to do with plugins directly, but 
it's more likely to be relevant for plugins as they're used across 
service-templates more often.


  was:
Using a plugin currently requires a user first installs the plugin (using 
PluginManager), then import the relevant plugin.yaml file in the service 
template file. The import will currently likely to point to a URL.

It should be simpler if a plugin contained its plugin.yaml as part of its wagon 
archive, and once installed, users should be able to import it more easily 
using a notation such as `plugins/openstack.yaml` (or perhaps `openstack.yaml` 
and have a fallback when importing that would iterate all plugins etc...)


> plugin.yaml importing
> -
>
> Key: ARIA-118
> URL: https://issues.apache.org/jira/browse/ARIA-118
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>Priority: Minor
>
> Using a plugin currently requires a user first installs the plugin (using 
> PluginManager), then import the relevant plugin.yaml file in the service 
> template file. The import will currently likely point to a URL, or be a path 
> relative to the service-template yaml file.
> Some ideas for improvement and easing the import;
>  - 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)
>  - 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.
>  - Perhaps ARIA should also support importing yaml files by using paths 
> relative to the service-template's package root (as opposed to only looking 
> for paths relative to the current yaml file)? Note that this could lead to 
> ambiguities in some cases.
> Note that the last two don't necessarily have to do with plugins directly, 
> but it's more likely to be relevant for plugins as they're used across 
> service-templates more often.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARIA-118) plugin.yaml importing

[Ran Ziv (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARIA-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ran Ziv updated ARIA-118:
-
Description: 
Using a plugin currently requires a user first installs the plugin (using 
PluginManager), then import the relevant plugin.yaml file in the service 
template file. The import will currently likely point to a URL, or be a path 
relative to the service-template yaml file.

Some ideas for improvement and easing the import;
 - 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)

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

 - Perhaps ARIA should also support importing yaml files by using paths 
relative to the service-template's package root (as opposed to only looking for 
paths relative to the current yaml file)? Note that this could lead to 
ambiguities in some cases.


Note that the last two don't necessarily have to do with plugins directly, but 
it's more likely to be relevant for plugins as they're used across 
service-templates more often.


  was:
Using a plugin currently requires a user first installs the plugin (using 
PluginManager), then import the relevant plugin.yaml file in the service 
template file. The import will currently likely point to a URL, or be a path 
relative to the service-template yaml file.

Some ideas for improvement and easing the import;
 - 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)
 - 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.
 - Perhaps ARIA should also support importing yaml files by using paths 
relative to the service-template's package root (as opposed to only looking for 
paths relative to the current yaml file)? Note that this could lead to 
ambiguities in some cases.


Note that the last two don't necessarily have to do with plugins directly, but 
it's more likely to be relevant for plugins as they're used across 
service-templates more often.



> plugin.yaml importing
> -
>
> Key: ARIA-118
> URL: https://issues.apache.org/jira/browse/ARIA-118
> Project: AriaTosca
>  Issue Type: Story
>Reporter: Ran Ziv
>Priority: Minor
>
> Using a plugin currently requires a user first installs the plugin (using 
> PluginManager), then import the relevant plugin.yaml file in the service 
> template file. The import will currently likely point to a URL, or be a path 
> relative to the service-template yaml file.
> Some ideas for improvement and easing the import;
>  - 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)
>  - 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.
>  - Perhaps ARIA should also support importing yaml files by using paths 
> relative to the service-template's package root (as opposed to only looking 
> for paths relative to the current yaml file)? Note that this could lead to 
> ambiguities in some cases.
> Note that the last two don't necessarily have to do with plugins directly, 
> but it's more likely to be relevant for plugins as they're used across 
> service-templates more often.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)