[OASIS Issue Tracker] (TOSCA-188) Requirements section should be turned to a map instead of list

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

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

noa koffman commented on TOSCA-188:
-----------------------------------

A few questions regarding the processing of requirements by the list ordering:
We believe that this is not the common case, in most cases, we think the user won't mind the processing order and a lot of thing that would optimally run in parallel will now be unnecessarily queued. Assuming that in most cases different requirements will be independent from each other, shouldn't the processing be parallel by default?
Another point to think about is a case where the list ordering and the explicit dependencies do not agree, should the explicit requirement be stronger when deciding the running order?
Also, is there a use case for a meaningful list order that we cannot translate in to explicit requirements between the nodes? 
If there is, by explicitly stating the order we can avoid the first problem and enable some requirements to be processed in parallel while others should be queued, however, the subject of the second problem still has to be decided.  


> Requirements section should be turned to a map instead of list
> --------------------------------------------------------------
>
>                 Key: TOSCA-188
>                 URL: https://issues.oasis-open.org/browse/TOSCA-188
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Bug
>          Components: Profile-YAML
>            Reporter: noa koffman
>
> Requirements section is currently a list, however since the get_attribute function allows to refer to a requirement by name, it forces the requirements names to be unique. This limitation implicitly forces the section to behave as a map, and I think this should be expressed explicitly by turning the section in to a map, like the current capabilities section.
> current situation:
> software:
>   type: tosca.nodes.SoftwareComponent
>   properties:...
>   attributes:
>     ip_address: {get_attribute: [ SELF, host, ip_address] } #which host???
>   requirements:
>      # the get attribute expression is referring to host, however there can be multiple "host" 
>      # requirements, and each can have different attribute values.
>     - host: server_be
>       relationship: tosca.relationships.HostedOn
>     - host: server_fe
>       relationship: tosca.relationships.HostedOn
> server_be:    
>     type: tosca.nodes.Compute
>     ...
>     
> server_fe:    
>     type: tosca.nodes.Compute
>     ...
> proposed fix:
> software:
>   type: tosca.nodes.SoftwareComponent
>   properties:...
>   attributes:
>     ip_address: {get_attribute: [ SELF, host_be, ip_address] }
>   requirements:
>     # in this case the reference will be mapped uniquely to the one matching requirement name. 
>     host_be:       # names are forced to be unique
>       target: server_be
>       relationship: tosca.relationships.HostedOn
>     host_fe:       # names are forced to be unique
>       target: server_fe
>       relationship: tosca.relationships.HostedOn
> server_be:    
>     type: tosca.nodes.Compute
>     ...
>     
> server_fe:    
>     type: tosca.nodes.Compute
>     ...



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