[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=30806#action_30806 ] 

Bryan Murray commented on TOSCA-22:
-----------------------------------

To fulfill my action item to provide use cases for versioning in general and a version attribute specifically, I offer the following use cases:

-  One ServiceTemplate references a specific version of another ServiceTemplate either to make sure a certain feature is available (need version >= x) or to avoid know issues with a later version (need version <= x). This use case was mentioned during the July 12 phone conference.

- A realized instance of a ServiceTemplate requires a specific version of another realized instance of a ServiceTemplate for similar reasons as described at design time above.

- A service broker will need a history of versions of a single ServiceTemplate. Some clients may be using one version, other clients may be using a different version. It will be important to a client to know if there are later versions to know if there is an upgrade from the version they have.

- An admin may want to know whether the current deployed version is different from the current designed version. In this case it can be assumed that if they are different the designed version is more recent.

- When the requires/provides capability feature is discussed, it may be important to define which version a capability should originate from because there are different levels of maturity of the capability in different versions of the ServiceTemplate.


Versioning defines the local scope of understanding. Some of these use cases imply it is important to understand what the upgrade path is for a ServiceTemplate.

Many of these use cases can be realized using a namespace to define the version of the template, however, some of the use cases can benefit from the use of a version attribute. A namespace works well if all that needs to be known is that the templates are different. A namespace works less well if versions will need to be ordered such that one version is newer than another (a specific format for namespace URI is required in order to locate the version information). A namespace is reasonable for machine evaluation, but less reasonable for human evaluation. XML namespaces tend to be used where there is some longevity in the document, whereas it is conceivable that a ServiceTemplate could change relatively often.

To drill into one of the use cases in more detail, I offer the following more formal statement of the requires/provides use case: "As a User, I want to select from the latest TOSCA service designs that satisfy a requirement (provide a capability), so that I do not need to see all of the intermediate versions and can see a reduced list of choices, to make template selection as easy as possible."

An example scenario is as follows:
- My application requires a JDBC 2.0 feature
- Vendor XYZ offers a template that provides JDBC 1.0 in version 1 and JDBC 2.0 in version 2.
- When I go to upgrade my application in the future, vendor XYZ offers a version 3 of their template that provides JDBC 4.0. My application requires JDBC 3.0 or greater.
- Tools should be able to show which versions of the template provide the capabilities my application requires. The final decision can be offered to the admin to perform the upgrade or not.


> 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