Re: Version support for different TOSCA types

2017-08-09 Thread 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

Re: TOSCA spec compliance on finding target node

2017-08-09 Thread 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

Re: Version support for different TOSCA types

2017-08-09 Thread 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

Re: Version support for different TOSCA types

2017-08-09 Thread 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

Re: Version support for different TOSCA types

2017-08-09 Thread 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

Re: Service Composition / Substitution Mapping

2017-08-09 Thread 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 -

Re: Version support for different TOSCA types

2017-08-09 Thread 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