[OASIS Issue Tracker] Commented: (TOSCA-41) Service Template versioning

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

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

Derek Palma commented on TOSCA-41:
----------------------------------

My contention is that Service Templates have to be self describing if they are going to be considered reusable entities. Some kind of self describing mechanism seems to be required for this so some kind of metadata needs to be provided. We can disagree on where it is stored and how much there is and the reasoning supported over it. 

I see versioning as a Service Template author and as a consumer. A repository can certainly hold the metadata, but the problem is when we move the Service Templates from one repo to another. We have to put the metadata somewhere. We could put it in the CSAR now that we have it instead of the Service Template. But we have to define it so the consumer's repo can understand receive it otherwise people will put it in the name of the ServiceTemplate or CSAR file (like what happened with Java jar files) or make their own descriptors or whatever.

Personally, I care more about portable metadata than having a specific version attribute. With semantically unspecific "tags" or key value pairs, the same effect can be achieved. But there has to be some way propagate the metadata.

I don't agree with the Java analogy. For me NodeTypes are closer to Java classes because NodeType is a class and the smallest unit of abstraction and Service Templates are closer to J2EE EARs or OSGI bundles than Java files. If you try using a tool to assemble such apps you hit the same issues. Check out OSGI which handles versioning of so called "bundles' which represent reusable components in an open component ecosystem.

Maybe the TC should just vote on:
1) Whether Service Templates should describe their version (semantics of a version attributes)
2) Whether Service Templates should carry any metadata, but the semantics are left unspecified

and if 1 and 2 are rejected, then some statement about how products can move ServiceTemplates portably across heteorgeneous repos stating this is out of scope. (Everyone can already move between their own repos)



> Service Template versioning
> ---------------------------
>
>                 Key: TOSCA-41
>                 URL: http://tools.oasis-open.org/issues/browse/TOSCA-41
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Sub-task
>          Components: Spec
>            Reporter: Derek Palma
>
> Service Template versioning. More specifically, model instance versioning (versus the entities being represented by the model). This kind of versioning treats a Service Template as a single unit (or entity instance) for which we may want to attach a version attribute. The version attribute would imply nothing more than some chronologic ordering in some version domain.  Note that it possible to version at a finer granularity such as the Node/Relationship Templates  or even versioning sub groups of these as a version set (I am not implying we should do this). The key idea is that we are implying that version n+1 was created based on a copy of version n and we assume this is important information to use to discriminate lineage and compatibility, i.e. that a user or software component may want to select by version. 

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