Re: Version support for different TOSCA types

[Tal Liron]

Yeah, that could be one use case. In the end it's just an extra metadata
field that users can do with as they please. It's hard to think of one
mechanism that would work for all intents.

On Wed, Aug 9, 2017 at 8:35 AM, Avia Efrat  wrote:

> First, I agree with both of you about not adding this currently to the ARIA
> core, as it is not certain that it is intended as a part of 1.0
>
> As for I meant by backwards-compatibility, I'll try to give an example:
> Suppose there is a cloud-provider database node type: cp.nodes.complexdb,
> which corresponds with the cloud-provider's implementation of this
> database. You interact with this database via API of version 1.
>
> After a new version (version 2) of the cloud provider is released, a new
> configurable feature is added to that database. It still represent the same
> type of database (the cloud provider treats it as the same), just with an
> extra feature.
>
> In such a case, I don't see an immediate need for a new node type, as the
> new database and old database represent the same logical entity. We could
> just create a new node type (like cr.nodes.complexdb.v2), but I think using
> a different version field better describes the differences between the
> version 1 database and version 2 database.
>
>
>
> On Wed, Aug 9, 2017 at 4:21 PM, Thomas Nadeau 
> wrote:
>
> >
> > > On Aug 9, 2017:9:12 AM, at 9:12 AM, Tal Liron  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  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  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 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?
> 

Re: TOSCA spec compliance on finding target node

[Maxim Orlov]

The support for satisfying a requirement according to a capability type was
just added as part of
https://github.com/apache/incubator-ariatosca/commit/df2b916e624719e5f77e29c1e893c55f88e15862

On Mon, Aug 7, 2017 at 6:30 PM, Tal Liron  wrote:

> I think you are talking about requirements? Some of the combinations you
> mention are for requirement declarations (at the node type) and some for
> requirement assignments (at the node template).
>
> Generally speaking, ARIA intends to support 100% of the TOSCA spec, so feel
> free to contribute. If a combination does not work, it is a bug.
>
> There is a known bug about requiring a capability without a template that
> is being worked on.
>
> On Mon, Aug 7, 2017 at 12:01 AM, Vaishnavi K.R  >
> wrote:
>
> > Hi,
> >
> >
> > I tried the following combinations in my service template,
> >
> >   1.  Type definition with capability type alone but node template having
> > any of the following,
> >  *   capability type alone
> >  *   capability name alone
> >  *   node type alone
> >  *   node name alone
> >  *   capability name and node name
> >  *   capability name and node type
> >  *   capability type and node type
> >  *   capability type and node type
> >   2.  Type definition with capability type and node type
> >  *   capability type alone
> >  *   capability name alone
> >  *   node type alone
> >  *   node name alone
> >  *   capability name and node name
> >  *   capability name and node type
> >  *   capability type and node type
> >  *   capability type and node type
> >
> > As per the TOSCA specification, the above are valid combinations.
> >
> > Will ARIA support all the above ?? If so, we wish to contribute.
> >
> > Looking forward to your comment.
> >
> >
> >
> > Thanks,
> >
> > /Vaish
> >
> > 
> > From: Tal Liron 
> > Sent: Tuesday, July 25, 2017 10:03:18 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: TOSCA spec compliance on finding target node
> >
> > It indeed should *not* be required. I just verified that it you are
> > correct, and a match is not made if only the capability is specified
> > without a node type/template.
> >
> > This is a regression, because it used to work correctly.
> >
> > There is currently work in progress to refactor that mechanism, so I will
> > add a test case to make sure the regression is fixed.
> >
> > See my test case and follow progress here:
> > https://issues.apache.org/jira/browse/ARIA-174
> >
> > On Tue, Jul 25, 2017 at 3:28 AM, Vaishnavi K.R <
> vaishnavi@ericsson.com
> > >
> > wrote:
> >
> > > Hi ARIA folks,
> > >
> > >
> > > I had a look at the source code of ARIA on how the target node is
> > > identified based on the requirement and capability information
> furnished
> > in
> > > the node template and its corresponding node type. But I find that only
> > few
> > > of the combinations are supported i.e., as per the TOSCA spec, in the
> > > requirement section of a node template, the 'node' option is not
> > mandatory,
> > > but ARIA expects that to be present.
> > >
> > >
> > > In my use-case, my node template has a requirement on a node which has
> a
> > > particular capability. So I just specify the capability type in my node
> > > template under the requirement section. As ARIA expects the 'node'
> option
> > > to be present, this use-case fails.
> > >
> > >
> > > So I wish to get clarified is there any specific reason for mandating
> the
> > > 'node' option or if TOSCA spec compliance on this target identification
> > > based on the capability name or type will be supported in the future
> > > versions?
> > >
> > >
> > > Thanks,
> > >
> > > /Vaish
> > >
> >
>

Re: Version support for different TOSCA types

[Avia Efrat]

First, I agree with both of you about not adding this currently to the ARIA
core, as it is not certain that it is intended as a part of 1.0

As for I meant by backwards-compatibility, I'll try to give an example:
Suppose there is a cloud-provider database node type: cp.nodes.complexdb,
which corresponds with the cloud-provider's implementation of this
database. You interact with this database via API of version 1.

After a new version (version 2) of the cloud provider is released, a new
configurable feature is added to that database. It still represent the same
type of database (the cloud provider treats it as the same), just with an
extra feature.

In such a case, I don't see an immediate need for a new node type, as the
new database and old database represent the same logical entity. We could
just create a new node type (like cr.nodes.complexdb.v2), but I think using
a different version field better describes the differences between the
version 1 database and version 2 database.



On Wed, Aug 9, 2017 at 4:21 PM, Thomas Nadeau 
wrote:

>
> > On Aug 9, 2017:9:12 AM, at 9:12 AM, Tal Liron  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  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  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 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. 

Re: Version support for different TOSCA types

[Thomas Nadeau]

> On Aug 9, 2017:9:12 AM, at 9:12 AM, Tal Liron  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  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  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 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:
> -

Re: Version support for different TOSCA types

[Tal Liron]

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.

On Wed, Aug 9, 2017 at 7:19 AM, Avia Efrat  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  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 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
> > > > >
> > > 

Re: Service Composition / Substitution Mapping

[Avia Efrat]

Currently, the support for substitution mapping is extremely limited. the
substitution_mapping section is parsed and validated, but nothing more.

However, supporting this feature (and hence, allowing for service
composition) is of high priority. Currently, we are at the the designing
phase - going over the spec to identify vague and ambiguous parts, and
consolidating TOSCA's pov regarding substitution mapping with the current
ARIA implementation.

Relevant Jira issue:
https://issues.apache.org/jira/browse/ARIA-292

On Tue, Aug 8, 2017 at 11:03 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> I have looked at the data you have provided.
> I am trying to catch up (understand) to current ARIA support for
> substitution mapping.
> What is supported today and what are the limitations/considerations?
> What is missing (hence the need for full implementation)?
> Do you have an working example or set of guidelines for using substitution
> mapping today?
> Or should I avoid it completely for now?
>
> - Steve B
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Monday, August 07, 2017 8:41 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Service Composition / Substitution Mapping
>
> Well, this is exactly what policies are for. :)
>
> Again, I think the rule of thumb should be that users put policies in place
> *only* if the defaults do not suffice.
>
> On Mon, Aug 7, 2017 at 6:42 PM, Ran Ziv  wrote:
>
> > The sensible defaults Tal's mentioned sound indeed sensible to me.
> > I'd also like users to have control over this, though I'm a bit
> > worried about us getting too carried away with how arbitrarily we use
> > policies for configuring, well, pretty much anything. It might not be
> > a problem right now but I'm not certain that will remain the case in
> > the future when the number of them grows..
> >
> >
> > On Wed, Aug 2, 2017 at 7:14 PM, Tal Liron  wrote:
> >
> > > Our goal with adding new "conventions" to ARIA, such as policies, is
> > > to always make them optional. The idea is that a plain-vanilla TOSCA
> > template
> > > would "just work" in ARIA via sensible defaults. The extra stuff is
> > > there if you know you are using ARIA and you want to make use of its
> features.
> > > (The opposite is true, too: we make sure that any additions are
> > > still
> > pure
> > > TOSCA and would be parsed validly by other TOSCA parsers.)
> > >
> > > On Wed, Aug 2, 2017 at 9:08 AM, DeWayne Filppi 
> > > wrote:
> > >
> > > > Cool.  Missed that.  That leaves things almost completely wide
> > > > open
> > from
> > > > the orchestrator side, IOW few predefined keys.  Too few IMHO, but
> > > > if everyone uses ARIA conventions it could work.
> > > >
> > > > On Tue, Aug 1, 2017 at 11:49 PM, Tal Liron  wrote:
> > > >
> > > > > I agree! Luckily metadata exists in the 1.0 spec. :)
> > > > >
> > > > > http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > > > YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#_
> > > Toc379455044
> > > > >
> > > > > On Tue, Aug 1, 2017 at 7:16 PM, DeWayne Filppi
> > > > > 
> > > > > wrote:
> > > > >
> > > > > > It occurs that it might be useful to be able to tag service
> > templates
> > > > > with
> > > > > > arbitrary meta-data.  Perhaps at one level carried forward
> > > > > > from a
> > > CSAR
> > > > > > manifest, but also user definable.  This would allow
> > > > > > inter-service references to be definitive, if desired.  This
> > > > > > could be implicitly
> > > > > defined
> > > > > > as a capability by the orchestrator, but some kind of special
> > > > requirement
> > > > > > type(s) would be needed to utilize it.  This way, external
> > > > > > repos
> > > could
> > > > be
> > > > > > used safely and directly without the separate load step.
> > > > > >
> > > > > > On Tue, Aug 1, 2017 at 12:43 PM, Tal Liron 
> > wrote:
> > > > > >
> > > > > > > Thanks for the kudos. :)
> > > > > > >
> > > > > > > This topic was discussed on this list a while ago. It's
> > > > > > > indeed
> > > tricky
> > > > > to
> > > > > > > get right, because TOSCA leaves a lot of room for the
> > orchestrator
> > > to
> > > > > > > implement.
> > > > > > >
> > > > > > > I'm thinking of it working something like this:
> > > > > > >
> > > > > > > 1. The reqs-and-caps engine by default will always look for
> > > > satisfiable
> > > > > > > capabilities within the currently instantiated service.
> > > > > > > HOWEVER,
> > if
> > > > > such
> > > > > > a
> > > > > > > capability is not present, the option is there to look for
> > another
> > > > > > > instantiated service that exposes the capabilities in
> > substitution
> > > > > > > mappings.
> > > > > > >
> > > > > > > 2. If we DON'T have another instantiated service, but DO
> > > > > > > have a
> > > > service
> > > > > > > template that could fit the bill, perhaps we need 

Re: Version support for different TOSCA types

[Avia Efrat]

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