[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=30848#action_30848 ] 

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

I believe it is absolutely necessary to allow users to use a version concept to differentiate among substitutable Service Templates. Anyone authoring or consuming Service Templates over time will require such a feature.

Thus far a Service Template is just an XML document. The inter document referencing mechanism currently specified is via URIs. The URI in the context of the CSAR is location specific. The draft has not attempted to use URIs as a way to uniquely identify a Service Template. There is no unique identifying information in a Service Template such as a GUID. Currently the following is possible using common interpretation of URIs:

A.1) Relative references. Assuming we package Service Templates in a CSAR, one Service Template could have relative references referring to the referenced Service Templates within the same CSR.

A.2) Absolute reference. A Service Template in the current CSAR could reference another Service Template in another CSAR (http://abc.com/stes/other.csar!/ServiceTemplates/stb.ste)

This just deals with referencing It assumes you knew which Service Templates to use (which version if version is important) when you built your referencing CSAR. Also, it could support a notion like selecting the newest if the absolute URI had some convention, but in the end it is just a URI and some content server is hosting the CSAR or Service Template.

Note that while referencing is useful, TOSCA is type based and allows type based resolution of required capabilities of a component. This means the reference denotes another Service Template to use with the referencing one, but the entities in both must be semantically compatible.

For versioning we must be able to understand that two or more Service Templates are different versions of the same service. The challenge we currently have is know that a set of Service Templates are the same kind of Service Template (e.g. Sugar CRM). The version attribute is superfluous until we address this. There are a few ways, all are not new:

B.1) By the name of the Service Template XML file. This is not very nice because different URI paths have to be used for each version in.
B.2) Add a unique name attribute such as a GUID or URI to the Service Template. All Service Templates with the same name are thought to be substitutable.
B.3) Give each Service Template a type notion so we can say the type is SugarCRMXYZ and any such types can be substituted for each other. The version attribute would just denote some chronological different among types. Making Service Templates a Type  (like Node and Relationship) has other advantages too. However, Service Template instances would still need to be identified so an instance ID of some form would still be required which is what B.2 is doing.
B.4) Define the Service Template as a function of the end points it provides. Service Templates which provide the same endpoints are considered substitutable. This is too weak.

I mention the above because there are really two use cases:

C.1) Referencing Service Templates from a Service Template

C.2) Differentiating a set of Service Templates in some way to enable some kind of selection (such as newest)

The referencing case seems addressed. I.e. if we know which Service Templates we want to use we can reference them.

The differentiating case would require some tool to look at the respective set of Service Templates, group them in to substitutable sets, and determine their discriminating attributes such as version. If a tool did not want to have to deal with absolute URIs or the content servers that host the needed Service Template, the tool could always make a copy (or the user could give the tool a copy) and it could be included in the CSAR or the environment could resolve specific absolute URIs with some convention. Hence, I'd leave absolute URIs out of the scope of TOSCA as well as any encoding of the URI string itself. TOSCA should define enough attributes in the Service Template itself to make discrimination possible. 
This leaves using something like B.2 or B.3 above to denote the kind of Service Template.

Other "tags" such as author, description, creation date, lineage, etc. would also be helpful (just look at what existing content management systems do)


> 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