Re: Version support for different TOSCA types

[Tal Liron]

wever the definition of the TOSCA version seems to be for a
> > different
> > >>>> purpose.
> > >>>> Here is a snippet:
> > >>>> It is important to provide a reliable, normative means to represent
> a
> > >>>> version string which enables the comparison and management of types
> > and
> > >>>> templates over time.
> > >>>> Therefore, the TOSCA TC intends to provide a normative version type
> > >>>> (string) for this purpose in future Working Drafts of this
> > >> specification.
> > >>>>
> > >>>> I also see text about TOSCA version comparison.
> > >>>>
> > >>>> It  seems like TOSCA version can be used by the parser to show
> > >>> differences
> > >>>> between 2 templates or to highlight types with different versions in
> > >> the
> > >>>> same template.
> > >>>> I think this is a useful feature to add to ARIA. What do you think?
> > >>>>
> > >>>> In general, what is the process to request an enhancement to ARIA?
> > >>>>
> > >>>>
> > >>>> Cheers
> > >>>> Steve B
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> -Original Message-
> > >>>> From: Tal Liron [mailto:t...@cloudify.co]
> > >>>> Sent: Tuesday, August 08, 2017 9:07 AM
> > >>>> To: dev@ariatosca.incubator.apache.org
> > >>>> Subject: Re: Version support for different TOSCA types
> > >>>>
> > >>>> My understanding has been that this is simply internal metadata,
> like
> > >> the
> > >>>> "description" field. There also does not seem any way to access the
> > >>>> version, e.g. by an intrinsic function.
> > >>>>
> > >>>> ARIA identifies a type by its name only, not by its version, so for
> > the
> > >>>> same parsing session you cannot have two types of the same name even
> > if
> > >>>> their version is different. If your understanding for TOSCA 1.0 is
> > >>>> different, and you please show me an example of different use?
> > >>>>
> > >>>> On Tue, Aug 8, 2017 at 2:28 AM, D Jayachandran <
> > >>>> d.jayachand...@ericsson.com>
> > >>>> wrote:
> > >>>>
> > >>>>> Ok Tal, I agree with having a property datatype as version and
> using
> > >>>>> them in my implementations. But to re-iterate I see the support for
> > >>>>> version metadata for different types ( node, artifact, attribute,
> > >>>>> capability, requirements ) in TOSCA 1.0 profile too. You can check
> > >> the
> > >>>>> section starting from "3.6.3 Artifact Type".
> > >>>>>
> > >>>>> Example from SPEC:
> > >>>>>
> > >>>>> 3.6.8.2
> > >>>>> Grammar
> > >>>>> Node Types
> > >>>>> have following grammar
> > >>>>> :
> > >>>>> <
> > >>>>> node_type_name
> > >>>>>> :
> > >>>>> derived_from: <
> > >>>>> parent_node_type_name
> > >>>>>>
> > >>>>> version: <
> > >>>>> version_number
> > >>>>>>
> > >>>>> description: <
> > >>>>> node_type_description
> > >>>>>>
> > >>>>> properties:
> > >>>>> <
> > >>>>> property_definitions
> > >>>>>>
> > >>>>> attributes:
> > >>>>> <
> > >>>>> attribute_definitions
> > >>>>>>
> > >>>>> requirements:
> > >>>>> -
> > >>>>> <
> > >>>>> requirement_definitions
> > >>>>>>
> > >>>>> capabilities:
> > >>>>> <
> > >>>>> capability_definitions
> > >>>>>>
> > >>>>> interfaces:
> > >>>>> <
> > >>>>> interface_definit

Re: Version support for different TOSCA types

[Avia Efrat]

First, I agree with both of you about not adding this currently to the ARIA
core, as it is not certain that it is intended as a part of 1.0

As for I meant by backwards-compatibility, I'll try to give an example:
Suppose there is a cloud-provider database node type: cp.nodes.complexdb,
which corresponds with the cloud-provider's implementation of this
database. You interact with this database via API of version 1.

After a new version (version 2) of the cloud provider is released, a new
configurable feature is added to that database. It still represent the same
type of database (the cloud provider treats it as the same), just with an
extra feature.

In such a case, I don't see an immediate need for a new node type, as the
new database and old database represent the same logical entity. We could
just create a new node type (like cr.nodes.complexdb.v2), but I think using
a different version field better describes the differences between the
version 1 database and version 2 database.



On Wed, Aug 9, 2017 at 4:21 PM, Thomas Nadeau <tnad...@lucidvision.com>
wrote:

>
> > On Aug 9, 2017:9:12 AM, at 9:12 AM, Tal Liron <t...@cloudify.co> wrote:
> >
> > Why just to add functionality? (You should use inheritance in that
> case.) A
> > new version of a type might as well also remove functionality, or really
> > change everything as you said,
> >
> > In any case, TOSCA 1.0 doesn't tell us what to do with versions, so at
> this
> > point we should indeed do nothing in ARIA core.
>
> I’d agree with that. Its tempting to do an ARIA-specificly
> supported
> extension to support this and then offer that as an update to TOSCA, but
> we should think through that carefully if that is indeed what we want to
> do.
>
> —Tom
>
>
> >
> > On Wed, Aug 9, 2017 at 7:19 AM, Avia Efrat <a...@cloudify.co> wrote:
> >
> >> Actually, I can see the version field used as a backwards-compatibility
> >> mechanism that will enable to keep the same node type, while adding
> >> functionality. (maybe even modifying functionality, but that is more
> >> complex).
> >>
> >> In general, I agree that the 1.0 spec is not clear about using this
> version
> >> field, but the fact that version is consistently mentioned as a field in
> >> all the types, allows imo for a possible use of it within ARIA. There is
> >> not such a usage example of the version field in the 1.0 spec, I agree.
> >>
> >> On Tue, Aug 8, 2017 at 8:40 PM, Tal Liron <t...@cloudify.co> wrote:
> >>
> >>> The process is simply to open a JIRA ticket. However, it may be better
> to
> >>> first discuss it on this mailing list.
> >>>
> >>> For this enhancement, I think it's important to spec out how such a
> tool
> >>> would look. Let's say the inputs are two templates. What would be the
> >>> output?
> >>>
> >>> At least for TOSCA 1.0, I think this type version feature might be of
> >> more
> >>> use for "meta" tools that might be built on top of ARIA and allow some
> >> kind
> >>> of search or analysis. For example, a tool to rummage through a huge
> >>> directory of templates (or CSAR files) and do a search for node
> templates
> >>> or types that inherit from a specific base type and have a version of X
> >> or
> >>> X or similar. I don't know if such tools should be included in
> >> ARIA
> >>> proper, but they can definitely make use of ARIA as an SDK.
> >>>
> >>> On Tue, Aug 8, 2017 at 11:02 AM, Steve Baillargeon <
> >>> steve.baillarg...@ericsson.com> wrote:
> >>>
> >>>> Hi Tal
> >>>>
> >>>> I see that TOSCA version is optional for all types.
> >>>> Clearly it is not used for "identification purpose".
> >>>>
> >>>> However the definition of the TOSCA version seems to be for a
> different
> >>>> purpose.
> >>>> Here is a snippet:
> >>>> It is important to provide a reliable, normative means to represent a
> >>>> version string which enables the comparison and management of types
> and
> >>>> templates over time.
> >>>> Therefore, the TOSCA TC intends to provide a normative version type
> >>>> (string) for this purpose in future Working Drafts of this
> >> specification.
> >>>>
> >>>> I also see text about TOSCA version comparison.
> >>>>
> >>>> It  seems like TOSCA version can be used b

Re: Version support for different TOSCA types

[Thomas Nadeau]

> On Aug 9, 2017:9:12 AM, at 9:12 AM, Tal Liron <t...@cloudify.co> wrote:
> 
> Why just to add functionality? (You should use inheritance in that case.) A
> new version of a type might as well also remove functionality, or really
> change everything as you said,
> 
> In any case, TOSCA 1.0 doesn't tell us what to do with versions, so at this
> point we should indeed do nothing in ARIA core.

I’d agree with that. Its tempting to do an ARIA-specificly supported
extension to support this and then offer that as an update to TOSCA, but
we should think through that carefully if that is indeed what we want to do.

—Tom


> 
> On Wed, Aug 9, 2017 at 7:19 AM, Avia Efrat <a...@cloudify.co> wrote:
> 
>> Actually, I can see the version field used as a backwards-compatibility
>> mechanism that will enable to keep the same node type, while adding
>> functionality. (maybe even modifying functionality, but that is more
>> complex).
>> 
>> In general, I agree that the 1.0 spec is not clear about using this version
>> field, but the fact that version is consistently mentioned as a field in
>> all the types, allows imo for a possible use of it within ARIA. There is
>> not such a usage example of the version field in the 1.0 spec, I agree.
>> 
>> On Tue, Aug 8, 2017 at 8:40 PM, Tal Liron <t...@cloudify.co> wrote:
>> 
>>> The process is simply to open a JIRA ticket. However, it may be better to
>>> first discuss it on this mailing list.
>>> 
>>> For this enhancement, I think it's important to spec out how such a tool
>>> would look. Let's say the inputs are two templates. What would be the
>>> output?
>>> 
>>> At least for TOSCA 1.0, I think this type version feature might be of
>> more
>>> use for "meta" tools that might be built on top of ARIA and allow some
>> kind
>>> of search or analysis. For example, a tool to rummage through a huge
>>> directory of templates (or CSAR files) and do a search for node templates
>>> or types that inherit from a specific base type and have a version of X
>> or
>>> X or similar. I don't know if such tools should be included in
>> ARIA
>>> proper, but they can definitely make use of ARIA as an SDK.
>>> 
>>> On Tue, Aug 8, 2017 at 11:02 AM, Steve Baillargeon <
>>> steve.baillarg...@ericsson.com> wrote:
>>> 
>>>> Hi Tal
>>>> 
>>>> I see that TOSCA version is optional for all types.
>>>> Clearly it is not used for "identification purpose".
>>>> 
>>>> However the definition of the TOSCA version seems to be for a different
>>>> purpose.
>>>> Here is a snippet:
>>>> It is important to provide a reliable, normative means to represent a
>>>> version string which enables the comparison and management of types and
>>>> templates over time.
>>>> Therefore, the TOSCA TC intends to provide a normative version type
>>>> (string) for this purpose in future Working Drafts of this
>> specification.
>>>> 
>>>> I also see text about TOSCA version comparison.
>>>> 
>>>> It  seems like TOSCA version can be used by the parser to show
>>> differences
>>>> between 2 templates or to highlight types with different versions in
>> the
>>>> same template.
>>>> I think this is a useful feature to add to ARIA. What do you think?
>>>> 
>>>> In general, what is the process to request an enhancement to ARIA?
>>>> 
>>>> 
>>>> Cheers
>>>> Steve B
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -Original Message-
>>>> From: Tal Liron [mailto:t...@cloudify.co]
>>>> Sent: Tuesday, August 08, 2017 9:07 AM
>>>> To: dev@ariatosca.incubator.apache.org
>>>> Subject: Re: Version support for different TOSCA types
>>>> 
>>>> My understanding has been that this is simply internal metadata, like
>> the
>>>> "description" field. There also does not seem any way to access the
>>>> version, e.g. by an intrinsic function.
>>>> 
>>>> ARIA identifies a type by its name only, not by its version, so for the
>>>> same parsing session you cannot have two types of the same name even if
>>>> their version is different. If your understanding for TOSCA 1.0 is
>>>> different, and you please show me an example of different use?
>>>> 
>>

Re: Version support for different TOSCA types

[Tal Liron]

Why just to add functionality? (You should use inheritance in that case.) A
new version of a type might as well also remove functionality, or really
change everything as you said,

In any case, TOSCA 1.0 doesn't tell us what to do with versions, so at this
point we should indeed do nothing in ARIA core.

On Wed, Aug 9, 2017 at 7:19 AM, Avia Efrat <a...@cloudify.co> wrote:

> Actually, I can see the version field used as a backwards-compatibility
> mechanism that will enable to keep the same node type, while adding
> functionality. (maybe even modifying functionality, but that is more
> complex).
>
> In general, I agree that the 1.0 spec is not clear about using this version
> field, but the fact that version is consistently mentioned as a field in
> all the types, allows imo for a possible use of it within ARIA. There is
> not such a usage example of the version field in the 1.0 spec, I agree.
>
> On Tue, Aug 8, 2017 at 8:40 PM, Tal Liron <t...@cloudify.co> wrote:
>
> > The process is simply to open a JIRA ticket. However, it may be better to
> > first discuss it on this mailing list.
> >
> > For this enhancement, I think it's important to spec out how such a tool
> > would look. Let's say the inputs are two templates. What would be the
> > output?
> >
> > At least for TOSCA 1.0, I think this type version feature might be of
> more
> > use for "meta" tools that might be built on top of ARIA and allow some
> kind
> > of search or analysis. For example, a tool to rummage through a huge
> > directory of templates (or CSAR files) and do a search for node templates
> > or types that inherit from a specific base type and have a version of X
> or
> > X or similar. I don't know if such tools should be included in
> ARIA
> > proper, but they can definitely make use of ARIA as an SDK.
> >
> > On Tue, Aug 8, 2017 at 11:02 AM, Steve Baillargeon <
> > steve.baillarg...@ericsson.com> wrote:
> >
> > > Hi Tal
> > >
> > > I see that TOSCA version is optional for all types.
> > > Clearly it is not used for "identification purpose".
> > >
> > > However the definition of the TOSCA version seems to be for a different
> > > purpose.
> > > Here is a snippet:
> > > It is important to provide a reliable, normative means to represent a
> > > version string which enables the comparison and management of types and
> > > templates over time.
> > > Therefore, the TOSCA TC intends to provide a normative version type
> > > (string) for this purpose in future Working Drafts of this
> specification.
> > >
> > > I also see text about TOSCA version comparison.
> > >
> > > It  seems like TOSCA version can be used by the parser to show
> > differences
> > > between 2 templates or to highlight types with different versions in
> the
> > > same template.
> > > I think this is a useful feature to add to ARIA. What do you think?
> > >
> > > In general, what is the process to request an enhancement to ARIA?
> > >
> > >
> > > Cheers
> > > Steve B
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@cloudify.co]
> > > Sent: Tuesday, August 08, 2017 9:07 AM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Version support for different TOSCA types
> > >
> > > My understanding has been that this is simply internal metadata, like
> the
> > > "description" field. There also does not seem any way to access the
> > > version, e.g. by an intrinsic function.
> > >
> > > ARIA identifies a type by its name only, not by its version, so for the
> > > same parsing session you cannot have two types of the same name even if
> > > their version is different. If your understanding for TOSCA 1.0 is
> > > different, and you please show me an example of different use?
> > >
> > > On Tue, Aug 8, 2017 at 2:28 AM, D Jayachandran <
> > > d.jayachand...@ericsson.com>
> > > wrote:
> > >
> > > > Ok Tal, I agree with having a property datatype as version and using
> > > > them in my implementations. But to re-iterate I see the support for
> > > > version metadata for different types ( node, artifact, attribute,
> > > > capability, requirements ) in TOSCA 1.0 profile too. You can check
> the
> > > > section starting from "3.6.3 Artifact Type".
> > > >
> > > > Ex

Re: Version support for different TOSCA types

[Avia Efrat]

Actually, I can see the version field used as a backwards-compatibility
mechanism that will enable to keep the same node type, while adding
functionality. (maybe even modifying functionality, but that is more
complex).

In general, I agree that the 1.0 spec is not clear about using this version
field, but the fact that version is consistently mentioned as a field in
all the types, allows imo for a possible use of it within ARIA. There is
not such a usage example of the version field in the 1.0 spec, I agree.

On Tue, Aug 8, 2017 at 8:40 PM, Tal Liron <t...@cloudify.co> wrote:

> The process is simply to open a JIRA ticket. However, it may be better to
> first discuss it on this mailing list.
>
> For this enhancement, I think it's important to spec out how such a tool
> would look. Let's say the inputs are two templates. What would be the
> output?
>
> At least for TOSCA 1.0, I think this type version feature might be of more
> use for "meta" tools that might be built on top of ARIA and allow some kind
> of search or analysis. For example, a tool to rummage through a huge
> directory of templates (or CSAR files) and do a search for node templates
> or types that inherit from a specific base type and have a version of X or
> X or similar. I don't know if such tools should be included in ARIA
> proper, but they can definitely make use of ARIA as an SDK.
>
> On Tue, Aug 8, 2017 at 11:02 AM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi Tal
> >
> > I see that TOSCA version is optional for all types.
> > Clearly it is not used for "identification purpose".
> >
> > However the definition of the TOSCA version seems to be for a different
> > purpose.
> > Here is a snippet:
> > It is important to provide a reliable, normative means to represent a
> > version string which enables the comparison and management of types and
> > templates over time.
> > Therefore, the TOSCA TC intends to provide a normative version type
> > (string) for this purpose in future Working Drafts of this specification.
> >
> > I also see text about TOSCA version comparison.
> >
> > It  seems like TOSCA version can be used by the parser to show
> differences
> > between 2 templates or to highlight types with different versions in the
> > same template.
> > I think this is a useful feature to add to ARIA. What do you think?
> >
> > In general, what is the process to request an enhancement to ARIA?
> >
> >
> > Cheers
> > Steve B
> >
> >
> >
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Tuesday, August 08, 2017 9:07 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Version support for different TOSCA types
> >
> > My understanding has been that this is simply internal metadata, like the
> > "description" field. There also does not seem any way to access the
> > version, e.g. by an intrinsic function.
> >
> > ARIA identifies a type by its name only, not by its version, so for the
> > same parsing session you cannot have two types of the same name even if
> > their version is different. If your understanding for TOSCA 1.0 is
> > different, and you please show me an example of different use?
> >
> > On Tue, Aug 8, 2017 at 2:28 AM, D Jayachandran <
> > d.jayachand...@ericsson.com>
> > wrote:
> >
> > > Ok Tal, I agree with having a property datatype as version and using
> > > them in my implementations. But to re-iterate I see the support for
> > > version metadata for different types ( node, artifact, attribute,
> > > capability, requirements ) in TOSCA 1.0 profile too. You can check the
> > > section starting from "3.6.3 Artifact Type".
> > >
> > > Example from SPEC:
> > >
> > > 3.6.8.2
> > > Grammar
> > > Node Types
> > > have following grammar
> > > :
> > > <
> > > node_type_name
> > > >:
> > > derived_from: <
> > > parent_node_type_name
> > > >
> > > version: <
> > > version_number
> > > >
> > > description: <
> > > node_type_description
> > > >
> > > properties:
> > > <
> > > property_definitions
> > > >
> > > attributes:
> > > <
> > > attribute_definitions
> > > >
> > > requirements:
> > > -
> > > <
> > > requirement_definitions
> > > >
> > > capabilities:
> > >

Re: Version support for different TOSCA types

[Tal Liron]

The process is simply to open a JIRA ticket. However, it may be better to
first discuss it on this mailing list.

For this enhancement, I think it's important to spec out how such a tool
would look. Let's say the inputs are two templates. What would be the
output?

At least for TOSCA 1.0, I think this type version feature might be of more
use for "meta" tools that might be built on top of ARIA and allow some kind
of search or analysis. For example, a tool to rummage through a huge
directory of templates (or CSAR files) and do a search for node templates
or types that inherit from a specific base type and have a version of X or
X or similar. I don't know if such tools should be included in ARIA
proper, but they can definitely make use of ARIA as an SDK.

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

> Hi Tal
>
> I see that TOSCA version is optional for all types.
> Clearly it is not used for "identification purpose".
>
> However the definition of the TOSCA version seems to be for a different
> purpose.
> Here is a snippet:
> It is important to provide a reliable, normative means to represent a
> version string which enables the comparison and management of types and
> templates over time.
> Therefore, the TOSCA TC intends to provide a normative version type
> (string) for this purpose in future Working Drafts of this specification.
>
> I also see text about TOSCA version comparison.
>
> It  seems like TOSCA version can be used by the parser to show differences
> between 2 templates or to highlight types with different versions in the
> same template.
> I think this is a useful feature to add to ARIA. What do you think?
>
> In general, what is the process to request an enhancement to ARIA?
>
>
> Cheers
> Steve B
>
>
>
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, August 08, 2017 9:07 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Version support for different TOSCA types
>
> My understanding has been that this is simply internal metadata, like the
> "description" field. There also does not seem any way to access the
> version, e.g. by an intrinsic function.
>
> ARIA identifies a type by its name only, not by its version, so for the
> same parsing session you cannot have two types of the same name even if
> their version is different. If your understanding for TOSCA 1.0 is
> different, and you please show me an example of different use?
>
> On Tue, Aug 8, 2017 at 2:28 AM, D Jayachandran <
> d.jayachand...@ericsson.com>
> wrote:
>
> > Ok Tal, I agree with having a property datatype as version and using
> > them in my implementations. But to re-iterate I see the support for
> > version metadata for different types ( node, artifact, attribute,
> > capability, requirements ) in TOSCA 1.0 profile too. You can check the
> > section starting from "3.6.3 Artifact Type".
> >
> > Example from SPEC:
> >
> > 3.6.8.2
> > Grammar
> > Node Types
> > have following grammar
> > :
> > <
> > node_type_name
> > >:
> > derived_from: <
> > parent_node_type_name
> > >
> > version: <
> > version_number
> > >
> > description: <
> > node_type_description
> > >
> > properties:
> > <
> > property_definitions
> > >
> > attributes:
> > <
> > attribute_definitions
> > >
> > requirements:
> > -
> > <
> > requirement_definitions
> > >
> > capabilities:
> > <
> > capability_definitions
> > >
> > interfaces:
> > <
> > interface_definitions
> > >
> > artifacts:
> > <
> > artifact_definitions
> > >
> >
> > Even am trying to understand the use-case which can be mapped to
> > version support with each of types.
> >
> > Is it like we can have same custom node types with different
> > version in my service template ?
> > In that case how can the node template choose a particular
> > version of the custom node type ?
> > Or Is the version only for the template author to track
> > changes about custom types over time ?
> >
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Tuesday, August 08, 2017 12:11 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Version support for different TOSCA types
> >
> > There is no special use of versions in TOSCA 1.0: it is up to y

RE: Version support for different TOSCA types

[Steve Baillargeon]

Hi Tal

I see that TOSCA version is optional for all types. 
Clearly it is not used for "identification purpose".

However the definition of the TOSCA version seems to be for a different purpose.
Here is a snippet:
It is important to provide a reliable, normative means to represent a version 
string which enables the comparison and management of types and templates over 
time. 
Therefore, the TOSCA TC intends to provide a normative version type (string) 
for this purpose in future Working Drafts of this specification.

I also see text about TOSCA version comparison.

It  seems like TOSCA version can be used by the parser to show differences 
between 2 templates or to highlight types with different versions in the same 
template.
I think this is a useful feature to add to ARIA. What do you think?

In general, what is the process to request an enhancement to ARIA?

 
Cheers
Steve B




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

My understanding has been that this is simply internal metadata, like the 
"description" field. There also does not seem any way to access the version, 
e.g. by an intrinsic function.

ARIA identifies a type by its name only, not by its version, so for the same 
parsing session you cannot have two types of the same name even if their 
version is different. If your understanding for TOSCA 1.0 is different, and you 
please show me an example of different use?

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

> Ok Tal, I agree with having a property datatype as version and using 
> them in my implementations. But to re-iterate I see the support for 
> version metadata for different types ( node, artifact, attribute, 
> capability, requirements ) in TOSCA 1.0 profile too. You can check the 
> section starting from "3.6.3 Artifact Type".
>
> Example from SPEC:
>
> 3.6.8.2
> Grammar
> Node Types
> have following grammar
> :
> <
> node_type_name
> >:
> derived_from: <
> parent_node_type_name
> >
> version: <
> version_number
> >
> description: <
> node_type_description
> >
> properties:
> <
> property_definitions
> >
> attributes:
> <
> attribute_definitions
> >
> requirements:
> -
> <
> requirement_definitions
> >
> capabilities:
> <
> capability_definitions
> >
> interfaces:
> <
> interface_definitions
> >
> artifacts:
> <
> artifact_definitions
> >
>
> Even am trying to understand the use-case which can be mapped to 
> version support with each of types.
>
> Is it like we can have same custom node types with different 
> version in my service template ?
> In that case how can the node template choose a particular 
> version of the custom node type ?
> Or Is the version only for the template author to track 
> changes about custom types over time ?
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, August 08, 2017 12:11 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Version support for different TOSCA types
>
> There is no special use of versions in TOSCA 1.0: it is up to you to 
> define properties or attributes or inputs of the "version" data type 
> and do with those as you please in your operation implementations. 
> TOSCA 1.1 takes it a step further and provides standardized metadata to nodes.
>
> It seems that you have a particular use case in mind. Can you 
> elaborate it to us? Perhaps we can together brainstorm a solution,
>
> On Tue, Aug 8, 2017 at 1:05 AM, D Jayachandran < 
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Tal,
> >
> > I agree version is now looked upon as a "data type" now. But does 
> > the orchestrator has any scope when it comes to comparing node types 
> > or templates depending on the version specified ?
> > Am more interested in this statement where the version is looked 
> > upon as a parameter when defining different types "TOSCA supports 
> > the concept of “reuse” of type definitions, as well as template 
> > definitions which could be version and change over time. "
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Monday, August 07, 2017 9:04 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Version support for different TOSCA types
> >
> > OK, you are referring to the "version" da

Re: Version support for different TOSCA types

[Tal Liron]

My understanding has been that this is simply internal metadata, like the
"description" field. There also does not seem any way to access the
version, e.g. by an intrinsic function.

ARIA identifies a type by its name only, not by its version, so for the
same parsing session you cannot have two types of the same name even if
their version is different. If your understanding for TOSCA 1.0 is
different, and you please show me an example of different use?

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

> Ok Tal, I agree with having a property datatype as version and using them
> in my implementations. But to re-iterate I see the support for version
> metadata for different types ( node, artifact, attribute, capability,
> requirements ) in TOSCA 1.0 profile too. You can check the section starting
> from "3.6.3 Artifact Type".
>
> Example from SPEC:
>
> 3.6.8.2
> Grammar
> Node Types
> have following grammar
> :
> <
> node_type_name
> >:
> derived_from: <
> parent_node_type_name
> >
> version: <
> version_number
> >
> description: <
> node_type_description
> >
> properties:
> <
> property_definitions
> >
> attributes:
> <
> attribute_definitions
> >
> requirements:
> -
> <
> requirement_definitions
> >
> capabilities:
> <
> capability_definitions
> >
> interfaces:
> <
> interface_definitions
> >
> artifacts:
> <
> artifact_definitions
> >
>
> Even am trying to understand the use-case which can be mapped to version
> support with each of types.
>
> Is it like we can have same custom node types with different
> version in my service template ?
> In that case how can the node template choose a particular version
> of the custom node type ?
> Or Is the version only for the template author to track changes
> about custom types over time ?
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Tuesday, August 08, 2017 12:11 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Version support for different TOSCA types
>
> There is no special use of versions in TOSCA 1.0: it is up to you to
> define properties or attributes or inputs of the "version" data type and do
> with those as you please in your operation implementations. TOSCA 1.1 takes
> it a step further and provides standardized metadata to nodes.
>
> It seems that you have a particular use case in mind. Can you elaborate it
> to us? Perhaps we can together brainstorm a solution,
>
> On Tue, Aug 8, 2017 at 1:05 AM, D Jayachandran <
> d.jayachand...@ericsson.com>
> wrote:
>
> > Hi Tal,
> >
> > I agree version is now looked upon as a "data type" now. But does the
> > orchestrator has any scope when it comes to comparing node types or
> > templates depending on the version specified ?
> > Am more interested in this statement where the version is looked upon
> > as a parameter when defining different types "TOSCA supports the
> > concept of “reuse” of type definitions, as well as template
> > definitions which could be version and change over time. "
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Monday, August 07, 2017 9:04 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Version support for different TOSCA types
> >
> > OK, you are referring to the "version" data type, and it is fully
> > supported in ARIA, which includes:
> >
> > 1. Strict adherence to the (rather odd) specification and its regex 2.
> > Proper support for TOSCA comparative constraints for versions
> > (greater_than, lesser_than, etc.) 3. Comparisons also work properly in
> > Python when comparing version instances
> >
> > On Mon, Aug 7, 2017 at 12:22 AM, D Jayachandran <
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi Tal,
> > >
> > > I was referring to the section 3.2.2  in TOSCA 1.0. It seems the
> > > version is part of both TOSCA 1.0 and TOSCA 1.1
> > >
> > > http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.pdf
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@cloudify.co]
> > > Sent: Friday, August 04, 2017 9:39 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Ver

RE: Version support for different TOSCA types

[D Jayachandran]

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

Example from SPEC:

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

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

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


Regards,
DJ

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

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

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

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

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

RE: Version support for different TOSCA types

[D Jayachandran]

Hi Tal,

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


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

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

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

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

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

Re: Version support for different TOSCA types

[Tal Liron]

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

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

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

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

RE: Version support for different TOSCA types

[D Jayachandran]

Hi Tal,

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

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

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

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

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

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

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

Re: Version support for different TOSCA types

[Tal Liron]

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

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

On Fri, Aug 4, 2017 at 7:05 AM, D Jayachandran 
wrote:

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