OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (TOSCA-201) Harmonize Properties and Capabilities in Node Types


    [ https://issues.oasis-open.org/browse/TOSCA-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50277#comment-50277 ] 

Matthew Rutkowski  edited comment on TOSCA-201 at 11/12/14 1:21 AM:
--------------------------------------------------------------------

Also, you may not understand that properties are not "hard requirements" but are malleable.  We have open issues that go back some time to allow us to allow "fuzzy logic" on property matching such as adding "best can" semantics which means they are NOT requirements in all cases, but could be "would be nice if" you had this interpretation.  This means even if you say 2 MB memory they orchestrator can still run u with 1 MB or 3 MB. it can be a request, not a requirement.  Like I want a Toyota Truck, must be model Z, can be years between x1 and x2, cost around $y dollars, and ideally color blue.  BUT fundamentally I need a Toyota truck and I can be ok if year is < x1 or color is not blue.


was (Author: mrutkows):
Also, you may not understand that properties are not "hard requirements" but are malleable.  We have open issues that go back some time to allow us to allow "fuzzy logic" on property matching such as adding "best can" semantics which means they are NOT requirements in all cases, but could be "would be nice if" you had this.

> Harmonize Properties and Capabilities in Node Types
> ---------------------------------------------------
>
>                 Key: TOSCA-201
>                 URL: https://issues.oasis-open.org/browse/TOSCA-201
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Improvement
>          Components: Profile-YAML
>            Reporter: Chris Lauwers
>            Priority: Minor
>
> It appears that both Properties and Capabilities are used to map Node Types to requirements without any clear distinction between the two mechanisms. Or, said a different way, both Properties and Capabilities are used to express the capabilities of node types. We should simplify things by harmonizing these two approaches and settle on one single way to express capabilities (e.g. by doing away with Properties on Node Types and only using Capabilities). 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]