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