[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] [OASIS Issue Tracker] (TOSCA-253) capability instead of property in Compute
|
Hi Chris, sorry for the long mail.
My concern is to assign the correct meaning to a ruleset.
In my understanding the capability is an important piece of semantic it represent "something" that the node is able to do much like " the output of a node" when you see the node as a black box from the outside.
So when there is a node that has a requirement you can look to the list of nodes available and find one that suit you.
That is all that the "word" capability suggests to the mind of the reader "If you have a capability, it means you have the power to do something".
How a node is done within the black box is described by the property that should be interpreted as "
quality or trait belonging and especially peculiar to an individual or thing" so "how this node is done?"
It is obvious that being done in a specific way make you capable to satisfy some requirement.
The relation is in any case clear: before you have a quality than you express the cabability to satisfy something it cannot be the other way round.
Said that on the boring semantic topic since we are defining rules these should be "in synch" with the common interpretation of semantic.
On the things you pointed out:
1) capabilities (at least in the XML syntax) have a complex structure where you can express a set of constraints etc. the only thing that concern me is to what avails all this grammar is created?
The question that I pose is "where and who is going to read the capabilities?".
In my interpretation not the orchestrator (at least not in a simple impementation of it) since there are the relations between the nodes that the orchestrator put faith into and I, as an orchestrator, will not recheck what the template and relations tell me: I give for granted that if you linked two nodes together you have verified the capability's requirement match.
In more complex orchestrator where I go beyond the single TOSCA file, but maybe I'm managing a set of TOSCA files and I want to place together different services or switch something on the fly or dynamically adjust some components since I need to scale stuff, I need to look at capability and requirements to know that node A required something and that was provided by node B that asserted to have the needed capability since it HAD some properties, now I scaled the node so I changed the attributes and/or properties this could mean that the provided capability could not match the requirement ... but are we sure that this is not just an overkill?
The TOSCA file is done by someone that SHOULD have written it to be "good to do the job", so if I stated that, in that topology, the node B can scale, all its configurations should be good for node A.
It seems a bit an overkill in modeling thinking that we want to model that has the "AI" to adjust requirements based on change in capabilities.
This especially when the example we have just install "apache" + "wordpress" without remembering that apache does not come with PHP and we are missing the PHP module.
So there is an over-complication in some aspects and an over-semplification on others.
2)
I have to read the YAML better BUT I really hope that the target of a relationship IS the node and not the capability; relationship is between nodes the fact that you CAN establish the relationship is that node A capability FIT the node B requirement. The graph is done with nodes and relationships that represents nodes and edges of the graph. I see now looking at the examples that the document of the YAML states some thing in the writing but than express something else in the examples: "The relationship templates listed as part of the relationship_templates block can be mapped to the list of RelationshipTemplate definitions provided as part of TopologyTemplate of a ServiceTemplate as described by the TOSCA v1.0 specification" (lines 1427) of the YAML doc BUT the relationship in example ad lines 2299 and following is completely far from the relationship original definition there is no source and target of the relation and the relation in the node is expressed in the requirement. Again I see that the YAML standard is simplifying the model by overloading in a section that should just describe a requirement also the "edge" of the relation. So the orchestrator has to read all the nodes and ... than it should read the edges and than find the root node and starting traversing the graph now instead it reads the nodes and than inside the requirement it find the pointer to the sibling so needs to build the edges from the nodes traversing them in a no specificed order. Also in the requirement it finds a "NAME OF A SPECIFIC NODE" not a description of a generic node so now go figure the generic .... you also get a relation_type but there are data spread in lots of places something is in the relationship_template. (sorry I know I can sound pissed of but I have really difficulty in understanding it ... as far as I can tell you the YAML document is much more complicated to understand than the XML ... the notation is easier to read but the grammar is counterintuitive, simplifying the model took its toll somewhere)
3) By god sake no!!! ... please ... :D the question is are we going to represent a graph or not? The orchestrator needs it (at least I cannot figure out a different way at the moment but I'm open to explanations). Obvioulsy you can have nested graph ... but I was understanding we were going for a simple profile.
4) Obvioulsy yes. Nodes are part of the service cannot be managed independently (that is why we have relations, or should have them) and that is why in the XML standard "plans" were in the service_template node at the same level of the topology template. In the topology_template you describe the expected configuration in the "plan" you describe how to execute it. In this I'm asking why the YAML went on a very different path from the XML specification there should be surely a proper answer for a so big change in the standard.
I also really could need the rationales behind some changes in the semantic of the XML ... not that I'm an XML fan, but that is for the world the published standard and some changes could require a better explanation.
On a thing I will not agree on a rule set is not possible to consider a semantinc structure much like another is like to say that the "rook" is much like the "bishop" since they can move lots of places on the board. If in the game you define different pieces there has to be a reason and is not correct to overload with different meaning "just because is easier".
I believe that TOSCA standard aims to describe a VERY complex thing ... how to deploy applications in the cloud describing all the needed stuff that could be "a lot": in my "simple" example I have lots of nodes and properties because, as we all know, enterprise applications need more that the things we can map on examples (for brevity); with TOSCA we do not want to install the example at line 160 of the YAML document since is not useful and failry incomplete. In that example we are hiding a lot into scripts; lot of things that could be other nodes in the TOSCA file. For this reason we need a VERY strict rule set where each section has a proper meaning.
My opinion is that capability and property are distinct sections, but I understand that this is not the actual vision of the TC and changing this could be a problem so my advice is remove the property as it could be the lesser harm.
Luca
> _________________________________________________________________________ > > Il 27 giugno 2015 alle 4.51 Chris Lauwers <lauwers@ubicity.com> ha scritto: > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]