[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=30844#action_30844 ] 

Doug Davis  commented on TOSCA-22:
----------------------------------

@Tobias, your Unix package example is,sort of, making my point.  People will probably 
have links between svc templates in two ways:
1 - they'll have a URL that represents the "latest" of something. And this means that when the
"latest" is updated, that URL will either have new content behind it or it'll redirect to GET
to point to something else.  But either way this is an explicit modification and not
done via some query asking for some unknown version that's bigger than some number.
Someone, or some process, explicitly decided to update what the "latest" means.  And that's 
very different from "version > 2" - which could return more than one.

2 - they'll update the source svc template to point to some newer version of the referenced
svc template.  Again, someone or some process will need to decide when this happens.
I don't see the usecase where someone specifies a query that can return more than
1 result and the deployer will be happy with some random choice.  I'm not aware of this random
factor ever being done in the Unix library cases.  Someone always needs to make the upgrade
explicitly otherwise its very hard to get reproducible/consistent results.

On the 7 points... actually just #5... a catalog of all templates is not going to work for your
usecase.  Having 5 templates that have a version # greater than 2 is meaningless unless
you also know what they're about.  Meaning, all 5 could be viable results of your query or
only one of them could be because the other 4 are not even for a svc template you care about.
A version # alone is not sufficient to do what you want.  What you need is some kind of
link or association between the templates so that you can say something like:
  starting with this "root" template, find all subsequent templates that have a version # > 2
and in order to do this there needs to be some kind of history/lineage/linkage between
the versions so the query engine can know whether or not any particular template is
a newer version of that "root".   And this entire process seems out of scope to me because its
getting into a template repository system.  I thought all we were defining was the template itself
and not the bits needed to version/manage the template - 'cause if we head down that path
I suspect the next thing someone will ask for is some kind of  "owner" property :-)   bleck

Let's keep it simple and just define the bare minimum for how to describe a single service
template (yes include the ability to reference reusable nested/sub-templates).  And if in v1.1 we 
decide that we need to do more we can always add it later.


> 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