> On Aug 9, 2017:9:12 AM, at 9:12 AM, Tal Liron <t...@cloudify.co> wrote:
> 
> Why just to add functionality? (You should use inheritance in that case.) A
> new version of a type might as well also remove functionality, or really
> change everything as you said,
> 
> In any case, TOSCA 1.0 doesn't tell us what to do with versions, so at this
> point we should indeed do nothing in ARIA core.

        I’d agree with that. Its tempting to do an ARIA-specificly supported
extension to support this and then offer that as an update to TOSCA, but
we should think through that carefully if that is indeed what we want to do.

        —Tom


> 
> On Wed, Aug 9, 2017 at 7:19 AM, Avia Efrat <a...@cloudify.co> wrote:
> 
>> 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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Reply via email to