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