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

[Tal Liron]

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  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: get_artifact function usage

[Tal Liron]

ARIA currently supports copying scripts remotely as part of the execution
plugin. They are expected to be in the CSAR. But this mechanism is
currently totally divorced from the TOSCA artifact structure.

On Wed, Sep 20, 2017 at 3:37 AM, D Jayachandran  wrote:

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