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-226) Proposal (incomplete) to change Requirement Def. from Ordered List to a Map


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

Chris Lauwers commented on TOSCA-226:
-------------------------------------

Two comments/questions:

1. Please remind us what the use case is for allowing multiple requirements with the same name? What functionality would we lose if we didn't allow this?
2. I presume that there are many scenarios where ordering of the requirements doesn't really matter. What if instead of ordering the requirements list, we made the need to fulfill requirements in a specific order explicit (for those requirements that need it) using "depends_on" or a "do_before" keynames (the value of the keyname would be the name(s) of other requirements in the same node type or its base types)? These keys would only be set when ordering matters.

> Proposal (incomplete) to change Requirement Def. from Ordered List to a Map
> ---------------------------------------------------------------------------
>
>                 Key: TOSCA-226
>                 URL: https://issues.oasis-open.org/browse/TOSCA-226
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: New Feature
>          Components: Profile-YAML
>    Affects Versions: CSD2
>            Reporter: Matthew Rutkowski 
>            Assignee: Thomas Spatzier 
>            Priority: Minor
>
> Currently, the listing of requirement definitions in Node Types are in the form of an Ordered List to assure determinism by type/template authors to provide deterministic order to orchestrators when fulfilling them.  
> Thomas proposes we make this a simple "map" (or hashmap), but this has acknowledged problems and cannot be done without a comprehensive proposal that addresses them including:
> - Hashmaps cannot have duplicate keynames however, TOSCA allows duplication of symbolic requirement names.
> - Maps are "sets" and have no order.
> In any event, we have a (potential) ordering problem  when Node Types are sublcassed and the child type adds new Requirement defintions.  There is currently no way to indicate how these new requirements introduced by the child Type should be ordered relative to the parents' requirements.



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