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
Example from SPEC:
have following grammar
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 ?
From: Tal Liron [mailto:t...@cloudify.co]
Sent: Tuesday, August 08, 2017 12:11 PM
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>
> 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. "
> -----Original Message-----
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Monday, August 07, 2017 9:04 PM
> To: email@example.com
> 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 <
> > 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: firstname.lastname@example.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
> > >