[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (TOSCA-22) TOSCA Versioning
[ http://tools.oasis-open.org/issues/browse/TOSCA-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30845#action_30845 ]
Derek Palma commented on TOSCA-22:
----------------------------------
Based on some discussion in our last TC call we agreed to break this issue into different sub tasks according to the kind of versioning that has come up in discussion in order to keep the use cases separate and concise and the discussion more focused.
1) 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. See this sub task at: https://tools.oasis-open.org/issues/browse/TOSCA-41
2) Modeled entity instance requirements. A model entity instance (Node/Relationship Template) may represent an entity which has a dependency on its own realization (i.e. the version of the deployment artifacts used to materialize it at deployment time) and/or the existence of components with specific versions on which it depends. For example, SugarCRM may need to be deployed into a specific version of Apache web server along with version 5.3 of the PHP Runtime. Such dependency semantics are used by most modern language library managers (perl, ruby, ...) , package mangers (RPM, Deb, MSI, ...), and component containers (OSGI, PHP, process engines, ...). See this sub task at: https://tools.oasis-open.org/issues/browse/TOSCA-42
3) Type versioning. A more general term is schema or type evolution. This idea would be applicable if a type A exists, and someone later wants to create a type A' which is intended to be like A but not A and not related in a typed manner . It is important to note that A' and A are completely different types with no way to reason the delta between them. If one wanted some type based on A, they'd create a subclass of A and specialize accordingly. The practical uses of schema versioning is usually to create a completely new set of types which offer a different set of semantics than the previous version, so this is more of a way of labeling schemas. See this sub task at: https://tools.oasis-open.org/issues/browse/TOSCA-43
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]