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

Reply via email to