[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:
http://example.com/mySugarCRM/2012/07
vs
http://example.com/mySugarCRM/2011/03
and people can search for the versioned/dated namespace - even using >, <, >= ....
or
http://example.com/mySugarCRM/v2
vs
http://example.com/mySugarCRM/v3
this allows for people to also have the "lineage property" implied - meaning I know that all sc templates
that start with:
http://example.com/mySugarCRM
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]