Hi Luca,
When I first started working with Tosca, I had exactly the same question you posed: how do we decide when to model something as a property of a node and when to model something as a capability of a node? It seemed there weren't any clear guidelines for
distinguishing between the two. Based on that, it seemed logical to propose eliminating one or the other.
After working with Tosca more, I'm developing a slightly different perspective. Rather than debating how capabilities are different from properties, I think it might be more useful to think about capabilities as more similar to node templates instead.
As Derek pointed out, you can use capabilities to model "re-usable semantics" very much the way node templates do. Unlike node templates, however, capabilities don't stand alone; instead, they are used to model "sub-components" of other node templates. As a
result, they also don't have an independent lifecycle but their lifecycle is managed instead as part of the "containing" node template's lifecycle.
So, rather than debating whether to eliminate properties in favor of capabilities, I would rather see a discussion about better alignment of capabilities and node templates:
- would it make sense to allow "capabilities" to have "requirements", the same way node templates do?
- Should the target of a relationship be a node rather than a capability?
- Should we allow node templates to contain other node templates (similar to the way node templates current contain capabilities)?
- Should we support node templates whose lifecycle is not managed independently but rather as part of a "containing" entity?
I believe this would make for a more productive discussion than debating whether to harmonize capabilities and properties.
Chris
-----Original Message-----
From: tosca@lists.oasis-open.org [
mailto:tosca@lists.oasis-open.org] On Behalf Of OASIS Issues Tracker
Sent: Thursday, June 25, 2015 10:58 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] [OASIS Issue Tracker] (TOSCA-253) capability instead of property in Compute
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
> 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: