[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=30849#action_30849 ] 

Doug Davis  commented on TOSCA-41:
----------------------------------

>> TOSCA should define enough attributes in the Service Template itself to make discrimination possible. 

Why?

C.2 sure seems out of scope to me since we're not defining a svc template repo and therefore do not need to define a selection mechanism.  We're defining, in dumbed-down terms, an import and export format for a service.  Not how to manage those import/export description files.

Let me give you an analogy.... Java is a descriptive language, much like Tosca is meant to be.
Java files change over time, much like a Tosca svc template.
Java files need to be versioned, some would claim the same as a Tosca svc template.
Does Java define a version "property" that all Java files must have so it can do this versioning? No.
Does Java define some kind of "discrimination" thingy so we know which Java files are of the same lineage? No.

Why?  Because all of this is handled by the Java repository - e.g. cvs.  The version string is metadata _about_ the Java file not part of the Java file itself and is under the control of the Java repository.  For a Java file to be portable to other systems we do not need to care about versioning, we just need to make sure that our Java file repo gives us the right version of each file of our complete app when we ask for it. How it manages to do that is out of scope of Java itself despite this being a critical aspect of how we deal with Java files.

Likewise, the notion of defining a "substitution type system" seems well beyond what we need to do for a v1 spec.   Do we really need this just to define the import/export descriptor file of a service?  I don't think so.

I'm very concerned about scope creep and about us not completing within a reasonable amount of time.  Now, maybe I still don't fully grok the usecases, or the importance of them, but I really think that we need to focus on the core set of features needed to define a service and nothing more.  Let v.next be where we worry about everything else.

> 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