[OASIS Issue Tracker] Commented: (TOSCA-22) TOSCA Versioning

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/TOSCA-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30843#action_30843 ] 

Tobias Kunze  commented on TOSCA-22:
------------------------------------

@Doug: the key use case I am after is to allow a user to depend on a Service Template (or Node Type or Node Template, etc., whatever the units of reuse are) that is provided by some provider and have the TOSCA container satisfy the reference. This is the standard model when it comes to libraries or e.g. Linux packages. For example, your application may depend on a Node Type that provides version 8.0.0.3 of WebSphere or higher. You know that you need v8 and you know you need at least Fix 3, hence >= 8.0.0.3. Do you want to benefit from further security fixes shipped in Fix 4 and onward? That's a matter of preference, but in any case where the software is provided to you by a third party, my guess is you would. Ditto in the library world, where you typically link against an shared object name (e.g. libxml) and a version so that the runtime linker can then resolve to a library that provides the required API.

With that in mind, I think my answers to your points above would be:

1. The version field is not just for human consumption but also for automatic dependency resolution by the container

2. This may be correct, but if we don't specify how a version might be discovered, we can't support such repositories later on as we discussed on our calls in the past.

3. Ditto. If the container is supposed to interpret the version, it needs to be discoverable in a standard way (and the rules of comparison, e.g. sorting and operators need to be standardized)

4. Yes

5. Not sure that's the case. The container could just build a catalog of all templates it has available

6. See above. It's the standard model for libraries or (Unix) packages

7. See my prior comment regarding version number comparison in the Linux distros I am familiar with

With respect to the examples you list, I think they might work IFF the standard specified how the version could be extracted from the URL. (That is, your examples might not work that well, but a related example, e.g. http://example.com/mySugarCRM;2012/07 might.)

> TOSCA Versioning
> ----------------
>
>                 Key: TOSCA-22
>                 URL: http://tools.oasis-open.org/issues/browse/TOSCA-22
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Paul Lipton 
>            Assignee: Tobias Kunze 
>
> Originally sub-issue 7 in TOSCA-20, called "NodeTypes should have a "Version" field ," no consensus was made on this at the 6/7/12 meeting. This lack of consensus was probably the result of unclear scope. Reconsidering on 6/14, the TC has decided that the scope of the versioning issue is greater than this, e.g., do we mean of model / version of entities / etc., and requests Tobias, as original proposer of the "seed issue" in TOSCA-20, to take ownership of this issue. 
> See minutes from both these meetings. Others are invited to contribute/comment, of course. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira