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