OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[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=30841#action_30841 ] 

Doug Davis  commented on TOSCA-22:

There are a couple of aspects of this that I've been thinking about - hopefully its coherent  :-)
1 - for the most part if we do add some human readable property to the model called 'version' that's
     really only there so someone/something outside of the tosca spec can make use of it, but doesn't 
     really have much semantic meaning to a tosca implementation, then ok -just one more field to ignore, 
     like a description field.

2 - the use of some kind of comparison thing (like "version > 2") is out of scope for us.  By this I mean
     we're not developing a tosca repository so how people actually construct a URL with these types of
     query expressions is not something we'll put into our spec - that's up to whatever repo people will
     store these things in, if any.

3 - while the definition of a tosca repo is out of scope for us, we should allow any URL to be  reference
     to a svc template - its just up to someone else  (or some other spec) to define how to construct it.

4 - in the WS* world we dont' have a "version" string we use the "namespace". And by this I don't just mean that
     each namespace is unique but its actually versioned with a date or a number.  This _could_ be
     used to get the same end result w/o the addition of a new property.

5 - however, having said all of that, the big thing that I keep thinking about is that in order for any kind of
     "version" propertyto work we're going to have to add an additional property to link the related
     svc templates.  

If we have 2 svc templates and one has version #2 and one has version #3.  And someone is looking for
a SugarCRM svc template that's version > 1.   How do they find it?  How do we know that these two svc templates
are both about SugarCRM? How do we know that they're version of the same basic service?  What I'm
getting at is that I think we'd need to introduce some static property that all svc templates of the same
lineage MUST share.  W/o this linkage between related svc templates I don't think we can do the
version comparison that people are looking for.

6 - this conversation reminds me a little of the UDDI dreams people had years ago.    We created these
     very rich (dare I same complex) T-Models so that computers could automagically search for a
     service and pick the right one.  In practice it never really happened that way.  I get the sense that this
     will fall into the same bucket.  Will people really be ok with deploying a service that not concretely 
    defined?  Will they really be happy to have two deployments of the same svc template result in two different
    things because in between those two deployments someone happen to add a new svc template to the
    tosca repo?    I would think that most people will want the upgrade to a new component of their svc
    to be something explicit and not implicit - meaning I have a hard time thinking that people will really use
    some sort of "version > 2" type of URL as a reference between svc templates.  It just seems too random
    for most "real" deployment models.  Customer will want consistency and guarantees, no?

   However, its worth noting that people are always free to have URL references between svc templates 
   since we can never control what a URL points to.  If could point to "version 2" of a svc or it could point
   to "the latest" version of a service.  We can't stop it, nor should we try.  But, that's not quite the same thing
   as introducing something into our model that's not fully defined or usable w/o a lot of other stuff to go
   around it (see #5).

7 - related to #5.  The meaning of a version string seem to really only make sense within the context of 
     the versioning repo that the svc template is stored into - not only because of #5, but because of Frank's
     question.  If we pick an integer I can see someone saying that their repo needs an m.n versioning scheme.
     I suspect that we'd be forced to model it as a string otherwise we're being too restrictive.
     And, unless we add that 'constant lineage' property to our model, the repo will need to extend our model
     to add it, and if they add that then they can add a 'version' property too.

In the end, I think the namespace can convey everything people are looking for:
and people can search for the versioned/dated namespace - even using >, <, >= ....


this allows for people to also have the "lineage property" implied - meaning I know that all sc templates
that start with:
are all part of the same lineage.  Of course, this isn't something that we mandate in the spec, its just a 
convention that people can follow.  This would allow us to avoid this entire rathole.  :-)

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