[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=59935#comment-59935 ] 

Luca Gioppo commented on TOSCA-253:
-----------------------------------

I think that defining a standard means defining strict rules for placing data so that all implementors can understand without any doubts what has to be written where.
This is what enable interoperability.
If we define two places that can be used intechangebly we are not writing a proper rule.
The fact that a capability is resusable semantics is not helping the overall semantic of the standard.
We could have reusable properties and that could be even more useful.
I understand that it has been used this way for long so changing could be a problem but a clarification on the "meaning" of all the section is required since at the moment they are not so clear and hte definition written in the document is not totally in line with the examples.
Maybe it could be easier to get rid of the property section that at the moment is redundant.
The sure thing is that as implementor I need to know what each section is for and when I need to set "how many CPU my Compute node have to have" where do I HAVE to write it? it cannot be something left on the decision of the implementor or some description files will not run on different orchestrator implementation.
In my case (for example) I interpret from the standard that to set the number of CPU I have to look at the property section and respect that writing and in installation phase I totally ignore the capability since for the sake of installation I do not care to check if requirement from node A towards node B is respected because either I have a beginning process that check the validity of the servicefile and pinpoint inconsistency or I'm sure that all the info are correct and requirement vs capabilities are respected so all I need is in the property section.
Conceptually at installation time capability is useless could be used just as a runtime exposure of value for run time relationship validation (does that node fit my requirements ... and again I would point the capability to attributes in that case).

Than there coudl be a lasting misinterpretation of the specification but this means that we can change the specification to get rid of properties since they are redundant and say that capability inherit all the burden, that is perfectly fine with me, but a change in the doc is needed (let alone the synch with the XML)

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