You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ariatosca.apache.org by D Jayachandran <d....@ericsson.com> on 2017/09/20 08:49:13 UTC
RE: Contribution for https://issues.apache.org/jira/browse/ARIA-118
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-<version>"
Please let me know if this fine with you.
Regards,
DJ
-----Original Message-----
From: Tal Liron [mailto:tal@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.jayachandran@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
Posted by Tal Liron <ta...@cloudify.co>.
1) Does ARIA actually support namespace_uri and namespace_prefix for each
import definition as defined in YAML 1.1 spec. See multi-line grammar below:
> imports:
> - file: <file_URI>
> repository: <repository_name>
> namespace_uri: <definition_namespace_uri>
> namespace_prefix: <definition_namespace_prefix>
>
This is in TOSCA 1.0, too. Repositories are supported. Namespaces aren't,
but we have an open JIRA.
2) What does ARIA do with this information today especially the namespace
> prefix? I guess it is currently ignored but could be used in the future (?)
>
Ignored for now.
> 3) When creating a type definition file, is it important to ensure all
> new type names defined in the imported file are using the declared
> namespace prefix (assuming namespace prefix is provided in the import
> definition)?
>
The convention is the dot notation, just like in the Simple Profile, e.g.
"tosca.capabilities.Container". First segment is the domain, second is the
type of the type (node, capability, data, etc.), and third is the short
name of the type in camel case.
E.g.: "ericsson.nodes.VirtualRouter"
> 4) Is it bad practice to mix new types from different namespace prefixes
> in the same type definition file (assuming namespace prefix is *not*
> provided in the import definition)?
>
Hard for me to say! I think it could make sense in certain uses.
> 5) For plugins, is it possible to support a more specific filename instead
> of a static/fixed name like plugin.yaml? What about using
> <plugin_name>-<plugin_version>.yaml? I see the need for ST authors to
> retrieve these files for analysis and the last thing I want to do is to
> rename them.
>
There are discussions afoot for redoing a lot of things with plugins... for
now I would say keep an eye on developments and voice your opinion as it
moves. We will make sure to get feedback from the community.
> 7) To simplify the import definition for plugins, the user should also be
> able to import a plugin name without specifying the version. For instance:
> - file: <plugin-name>
> repository: plugins
> Here <plugin_name> is an alias always pointing to the latest version of
> the <plugin_name>-<plugin_version>.yaml file.
>
There's just a general mess between the import and the use of policies for
plugins. We would want to unify the two and make it more transparent.
RE: Contribution for https://issues.apache.org/jira/browse/ARIA-118
Posted by Steve Baillargeon <st...@ericsson.com>.
Hi
I have few follow-up questions/comments related to import definitions and plugins.
1) Does ARIA actually support namespace_uri and namespace_prefix for each import definition as defined in YAML 1.1 spec. See multi-line grammar below:
imports:
- file: <file_URI>
repository: <repository_name>
namespace_uri: <definition_namespace_uri>
namespace_prefix: <definition_namespace_prefix>
2) What does ARIA do with this information today especially the namespace prefix? I guess it is currently ignored but could be used in the future (?)
3) When creating a type definition file, is it important to ensure all new type names defined in the imported file are using the declared namespace prefix (assuming namespace prefix is provided in the import definition)?
4) Is it bad practice to mix new types from different namespace prefixes in the same type definition file (assuming namespace prefix is *not* provided in the import definition)?
5) For plugins, is it possible to support a more specific filename instead of a static/fixed name like plugin.yaml? What about using <plugin_name>-<plugin_version>.yaml? I see the need for ST authors to retrieve these files for analysis and the last thing I want to do is to rename them.
6) The user should be able to import a specific yaml file using - file: <plugin_name>-<plugin_version> with repository: plugins as described earlier by DJ. The <plugin_name>-<plugin_version> is an alias for the plugin_name>-<plugin_version>.yaml file.
7) To simplify the import definition for plugins, the user should also be able to import a plugin name without specifying the version. For instance:
- file: <plugin-name>
repository: plugins
Here <plugin_name> is an alias always pointing to the latest version of the <plugin_name>-<plugin_version>.yaml file.
Regards
Steve B
-----Original Message-----
From: Tal Liron [mailto:tal@cloudify.co]
Sent: Friday, October 20, 2017 11:56 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118
That looks good to me! Any thoughts from other committers?
On Fri, Oct 20, 2017 at 4:37 AM, D Jayachandran <d.jayachandran@ericsson.com
> wrote:
> 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: <plugin-name>-<version>
> repository: plugins
> - file: <plugin-name>-<version>
> 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:tal@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.jayachandran@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.baillargeon@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:
> > - <file_URI_1>
> > - <file_URI_2>
> > 3.5.8.2.2 Multi-line grammar
> > imports:
> > - file: <file_URI>
> > repository: <repository_name>
> > namespace_uri: <definition_namespace_uri>
> > namespace_prefix: <definition_namespace_prefix>
> >
> > -Steve B
> >
> > -----Original Message-----
> > From: Tal Liron [mailto:tal@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
> > <import_name> 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 <import_name> 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.jayachandran@ericsson.com
> > > wrote:
> >
> > > Hi Tal,
> > >
> > > As per the grammer in the SPEC, seems the import should take a
> > > <import_name>. Your example dint have a <import_name> but started
> > > with respository as such.
> > >
> > > <import_name>:
> > >
> > > file: <file_URI>
> > >
> > > repository: <repository_name>
> > >
> > > namespace_uri: <definition_namespace_uri>
> > >
> > > namespace_prefix: <definition_namespace_prefix>
> > >
> > >
> > > With your example can we have multiple repositories ?
> > >
> > >
> > > Regards,
> > > DJ
> > >
> > > -----Original Message-----
> > > From: Tal Liron [mailto:tal@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.jayachandran@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:tal@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.jayachandran@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-<version>"
> > > > > Please let me know if this fine with you.
> > > > >
> > > > >
> > > > > Regards,
> > > > > DJ
> > > > >
> > > > > -----Original Message-----
> > > > > From: Tal Liron [mailto:tal@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.jayachandran@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
Posted by Tal Liron <ta...@cloudify.co>.
That looks good to me! Any thoughts from other committers?
On Fri, Oct 20, 2017 at 4:37 AM, D Jayachandran <d.jayachandran@ericsson.com
> wrote:
> 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: <plugin-name>-<version>
> repository: plugins
> - file: <plugin-name>-<version>
> 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:tal@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.jayachandran@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.baillargeon@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:
> > - <file_URI_1>
> > - <file_URI_2>
> > 3.5.8.2.2 Multi-line grammar
> > imports:
> > - file: <file_URI>
> > repository: <repository_name>
> > namespace_uri: <definition_namespace_uri>
> > namespace_prefix: <definition_namespace_prefix>
> >
> > -Steve B
> >
> > -----Original Message-----
> > From: Tal Liron [mailto:tal@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
> > <import_name> 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 <import_name> 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.jayachandran@ericsson.com
> > > wrote:
> >
> > > Hi Tal,
> > >
> > > As per the grammer in the SPEC, seems the import should take a
> > > <import_name>. Your example dint have a <import_name> but started
> > > with respository as such.
> > >
> > > <import_name>:
> > >
> > > file: <file_URI>
> > >
> > > repository: <repository_name>
> > >
> > > namespace_uri: <definition_namespace_uri>
> > >
> > > namespace_prefix: <definition_namespace_prefix>
> > >
> > >
> > > With your example can we have multiple repositories ?
> > >
> > >
> > > Regards,
> > > DJ
> > >
> > > -----Original Message-----
> > > From: Tal Liron [mailto:tal@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.jayachandran@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:tal@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.jayachandran@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-<version>"
> > > > > Please let me know if this fine with you.
> > > > >
> > > > >
> > > > > Regards,
> > > > > DJ
> > > > >
> > > > > -----Original Message-----
> > > > > From: Tal Liron [mailto:tal@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.jayachandran@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
Posted by D Jayachandran <d....@ericsson.com>.
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: <plugin-name>-<version>
repository: plugins
- file: <plugin-name>-<version>
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:tal@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.jayachandran@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.baillargeon@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:
> - <file_URI_1>
> - <file_URI_2>
> 3.5.8.2.2 Multi-line grammar
> imports:
> - file: <file_URI>
> repository: <repository_name>
> namespace_uri: <definition_namespace_uri>
> namespace_prefix: <definition_namespace_prefix>
>
> -Steve B
>
> -----Original Message-----
> From: Tal Liron [mailto:tal@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
> <import_name> 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 <import_name> 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.jayachandran@ericsson.com
> > wrote:
>
> > Hi Tal,
> >
> > As per the grammer in the SPEC, seems the import should take a
> > <import_name>. Your example dint have a <import_name> but started
> > with respository as such.
> >
> > <import_name>:
> >
> > file: <file_URI>
> >
> > repository: <repository_name>
> >
> > namespace_uri: <definition_namespace_uri>
> >
> > namespace_prefix: <definition_namespace_prefix>
> >
> >
> > With your example can we have multiple repositories ?
> >
> >
> > Regards,
> > DJ
> >
> > -----Original Message-----
> > From: Tal Liron [mailto:tal@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.jayachandran@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:tal@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.jayachandran@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-<version>"
> > > > Please let me know if this fine with you.
> > > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > > > -----Original Message-----
> > > > From: Tal Liron [mailto:tal@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.jayachandran@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
Posted by Tal Liron <ta...@cloudify.co>.
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.jayachandran@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.baillargeon@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:
> - <file_URI_1>
> - <file_URI_2>
> 3.5.8.2.2 Multi-line grammar
> imports:
> - file: <file_URI>
> repository: <repository_name>
> namespace_uri: <definition_namespace_uri>
> namespace_prefix: <definition_namespace_prefix>
>
> -Steve B
>
> -----Original Message-----
> From: Tal Liron [mailto:tal@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
> <import_name> 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 <import_name> 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.jayachandran@ericsson.com
> > wrote:
>
> > Hi Tal,
> >
> > As per the grammer in the SPEC, seems the import should take a
> > <import_name>. Your example dint have a <import_name> but started with
> > respository as such.
> >
> > <import_name>:
> >
> > file: <file_URI>
> >
> > repository: <repository_name>
> >
> > namespace_uri: <definition_namespace_uri>
> >
> > namespace_prefix: <definition_namespace_prefix>
> >
> >
> > With your example can we have multiple repositories ?
> >
> >
> > Regards,
> > DJ
> >
> > -----Original Message-----
> > From: Tal Liron [mailto:tal@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.jayachandran@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:tal@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.jayachandran@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-<version>"
> > > > Please let me know if this fine with you.
> > > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > > > -----Original Message-----
> > > > From: Tal Liron [mailto:tal@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.jayachandran@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
Posted by D Jayachandran <d....@ericsson.com>.
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.baillargeon@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:
- <file_URI_1>
- <file_URI_2>
3.5.8.2.2 Multi-line grammar
imports:
- file: <file_URI>
repository: <repository_name>
namespace_uri: <definition_namespace_uri>
namespace_prefix: <definition_namespace_prefix>
-Steve B
-----Original Message-----
From: Tal Liron [mailto:tal@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 <import_name> 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 <import_name> 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.jayachandran@ericsson.com
> wrote:
> Hi Tal,
>
> As per the grammer in the SPEC, seems the import should take a
> <import_name>. Your example dint have a <import_name> but started with
> respository as such.
>
> <import_name>:
>
> file: <file_URI>
>
> repository: <repository_name>
>
> namespace_uri: <definition_namespace_uri>
>
> namespace_prefix: <definition_namespace_prefix>
>
>
> With your example can we have multiple repositories ?
>
>
> Regards,
> DJ
>
> -----Original Message-----
> From: Tal Liron [mailto:tal@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.jayachandran@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:tal@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.jayachandran@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-<version>"
> > > Please let me know if this fine with you.
> > >
> > >
> > > Regards,
> > > DJ
> > >
> > > -----Original Message-----
> > > From: Tal Liron [mailto:tal@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.jayachandran@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
Posted by Steve Baillargeon <st...@ericsson.com>.
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:
- <file_URI_1>
- <file_URI_2>
3.5.8.2.2 Multi-line grammar
imports:
- file: <file_URI>
repository: <repository_name>
namespace_uri: <definition_namespace_uri>
namespace_prefix: <definition_namespace_prefix>
-Steve B
-----Original Message-----
From: Tal Liron [mailto:tal@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 <import_name> 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 <import_name> 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.jayachandran@ericsson.com
> wrote:
> Hi Tal,
>
> As per the grammer in the SPEC, seems the import should take a
> <import_name>. Your example dint have a <import_name> but started with
> respository as such.
>
> <import_name>:
>
> file: <file_URI>
>
> repository: <repository_name>
>
> namespace_uri: <definition_namespace_uri>
>
> namespace_prefix: <definition_namespace_prefix>
>
>
> With your example can we have multiple repositories ?
>
>
> Regards,
> DJ
>
> -----Original Message-----
> From: Tal Liron [mailto:tal@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.jayachandran@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:tal@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.jayachandran@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-<version>"
> > > Please let me know if this fine with you.
> > >
> > >
> > > Regards,
> > > DJ
> > >
> > > -----Original Message-----
> > > From: Tal Liron [mailto:tal@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.jayachandran@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
Posted by Tal Liron <ta...@cloudify.co>.
So, this is one of the cases where the spec seems to be wrong: the
<import_name> 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 <import_name> 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.jayachandran@ericsson.com
> wrote:
> Hi Tal,
>
> As per the grammer in the SPEC, seems the import should take a
> <import_name>. Your example dint have a <import_name> but started with
> respository as such.
>
> <import_name>:
>
> file: <file_URI>
>
> repository: <repository_name>
>
> namespace_uri: <definition_namespace_uri>
>
> namespace_prefix: <definition_namespace_prefix>
>
>
> With your example can we have multiple repositories ?
>
>
> Regards,
> DJ
>
> -----Original Message-----
> From: Tal Liron [mailto:tal@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.jayachandran@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:tal@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.jayachandran@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-<version>"
> > > Please let me know if this fine with you.
> > >
> > >
> > > Regards,
> > > DJ
> > >
> > > -----Original Message-----
> > > From: Tal Liron [mailto:tal@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.jayachandran@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
Posted by D Jayachandran <d....@ericsson.com>.
Hi Tal,
As per the grammer in the SPEC, seems the import should take a <import_name>. Your example dint have a <import_name> but started with respository as such.
<import_name>:
file: <file_URI>
repository: <repository_name>
namespace_uri: <definition_namespace_uri>
namespace_prefix: <definition_namespace_prefix>
With your example can we have multiple repositories ?
Regards,
DJ
-----Original Message-----
From: Tal Liron [mailto:tal@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.jayachandran@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:tal@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.jayachandran@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-<version>"
> > Please let me know if this fine with you.
> >
> >
> > Regards,
> > DJ
> >
> > -----Original Message-----
> > From: Tal Liron [mailto:tal@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.jayachandran@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
Posted by Tal Liron <ta...@cloudify.co>.
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.jayachandran@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:tal@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.jayachandran@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-<version>"
> > Please let me know if this fine with you.
> >
> >
> > Regards,
> > DJ
> >
> > -----Original Message-----
> > From: Tal Liron [mailto:tal@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.jayachandran@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
Posted by D Jayachandran <d....@ericsson.com>.
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:tal@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.jayachandran@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-<version>"
> Please let me know if this fine with you.
>
>
> Regards,
> DJ
>
> -----Original Message-----
> From: Tal Liron [mailto:tal@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.jayachandran@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
Posted by Tal Liron <ta...@cloudify.co>.
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.jayachandran@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-<version>"
> Please let me know if this fine with you.
>
>
> Regards,
> DJ
>
> -----Original Message-----
> From: Tal Liron [mailto:tal@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.jayachandran@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
> >
>