[OASIS Issue Tracker] (TOSCA-253) capability instead of property in Compute

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ 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)