[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
|
NO I really do not agree. When a standard defines sections it has to be clear on "what things are placed where", if it is the same placing properties here or there why bothering to set a rule? If I have to write an editor where does it HAVE to write the property? In the property section of the Capability section or in the property section of the node itself? Which is the "MEANING" of the sections? In the standard Capabilities have to be used just to check if the node matches the requirement of another node and to see if I can substitute that node with another of equal set capabilities; obviously I need to access the properties to understand if that node has the required capabilities, but there is not the place where I force the state there is the place where I expose the current state for matching operations. "TOSCA allows for expressing requirements and capabilities of components of a service. This can be done, for example, to express that one component depends on (requires) a feature provided by another component, or to express that a component has certain requirements against the hosting environment such as for the allocation of certain resources or the enablement of a specific mode of operation." The place that the standard declare that has to be used to FORCE the state is the property section of the node: "Properties: Specifies initial values for one or more of the Node Type Properties of the Node Type providing the property definitions in the concrete context of the Node Template."
Is obvious that we can use the properties in the Capability section for any purpose, but we need to restrict the usage to a proper way: "the orchestrator looks at the capabilities's properties only when it has to check if a requirement is matched" "the orchestrator read a node property in the property section when it has to decide which state to assign to a node". It is obvious that the 99% of the times the value will be the same and that all of this is redundand (standards are highly redundant) but we can suggest that the orchestrator just keep a pointer to the property or that the capability's properties are all red with a get_property operation. The sure thing is that properties in the capability are READ-ONLY since the function is announcing to the world my capability, do you want to change something go to the node's property section.
BTW I really believe that Capability is there for REAL future implementation where the TOSCA standard will be widely used and we will be able to really have someting to do substitutions, right now I'm not planning on using capabilities much since my topology states which node link to which and if I made the relation I'm pretty sure that the two have the capabilities to support each other. I always interpreted the capabilities as more "editor oriented"; that when an editor allows me to draw a topology it will use the capabilities to help me to draw something that work so if I draw a relation from node1 to node2 and node 2 does not have the capability I need the editor should warn me to check things. At runtime I see little use in capabilities unless on autoscaling scenario but again I believe that even in that case there should be other places to express things.
In the end a standard that leaves this wide interpretation option needs to be tightened up or interoperability will be VERY difficult since implementors will be free to write properties all over the places and than we will have hard time in finding a portable TOSCA file since I will read the node properties, you just the capabilities, anpother both and another one will place them somewhere else.
So as you see I will argue quite a bit on this untill you manage to explain me better the override of assignment. :D
Luca
> _________________________________________________________________________ > > > Il 18 giugno 2015 alle 17.04 Chris Lauwers <lauwers@ubicity.com> ha scritto: > > > > > > Properties can be in a node or in a capability of a node. Either way, they "force" the state of that node, and they can be retrieved using the get_property function (the get_property function has an option to look in a specific capability). Capabilities and properties can almost be used interchangeably, except that capabilities can be used to satisfy requirements. > > > > -----Original Message----- > > From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of OASIS Issues Tracker > > Sent: Wednesday, June 17, 2015 12:42 AM > > To: tosca@lists.oasis-open.org > > Subject: [tosca] [OASIS Issue Tracker] (TOSCA-253) capability instead of property in Compute > > > > > > [ https://issues.oasis-open.org/browse/TOSCA-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59809#comment-59809 ] > > > > Luca Gioppo commented on TOSCA-253: > > ----------------------------------- > > > > Sorry but I do not completely agree. > > As I understood (but the TC defined so you have more knowledge on this) from the spec the capability is something that is intended to declare to the world "I'm capable to do this so if you need someone with 4 CPU know I've got them". > > Is obvious that that information is redundant with the one in the property section where we should find the information of the CPU numbers and it should be consistent (that is 4 CPU in the example). > > The problem is with orchestrator that being DUMB need to know where to search for properties in the sense that those are the ones that are user to FORCE THE STATE (this should be the meaning in the specs). > > > > So in this case when the orchestrator needs to execute a get_property where does it read it? From the capabilities or the properties or both? > > I believe that if we define a "meaning" we should stick to it even if this generate redundancy so if the place to declare the state is in the property section (not the one in the capability, but the child of the node) than let us use just that and maybe in the capability we place the get_property to express the fact that after we force the property state than the node will offer that capability. > > > > I usually think that in IT we hack through shortcuts since is faster and it is "in the end the same thing" which is true untill you run in the exception where you need to do otherwise. > > > > In the specs we have lots of entities that make use of the "property" element since we defined the type, but the meaning of that property tag in the context changes and we cannot treat all properties in the same way otherwise it becomes useless to have two places to define them. > > In this case since we need to define a generic node_template either we remove the property section and we state that we just use the capability with its own properties or we force all node-types to write things in the right place (let's decide the one). > > But at the moment I see that there are example that uses property section and Capability section with the same expected behaviour for the orchestrator and this does not help interoperability or a clean representation in my opinion. > > Luca > > > > > capability instead of property in Compute > > > ----------------------------------------- > > > > > > Key: TOSCA-253 > > > URL: https://issues.oasis-open.org/browse/TOSCA-253 > > > Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC > > > Issue Type: Bug > > > Components: Profile-YAML > > > Affects Versions: CSD03 > > > Reporter: Luca Gioppo > > > Priority: Critical > > > Labels: misinterpretation > > > > > > In example H.1.2.4, but in general in all the specification the > > > Compute node has not properties and the properties inside the > > > Capability definition are used, but this does not respect the > > > spcification where the "expected state is written in the property > > > section" the Capability just state that that node offer the capability > > > of being a host and having a OS but should not used in place of > > > "state" declaration > > > > > > > > -- > > This message was sent by Atlassian JIRA > > (v6.2.2#6258) > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]