[OASIS Issue Tracker] (TOSCA-236) CLOSE - Mark IaaS Node Types as "substitutable" since the Orchestrator can determine impl. by default

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

     [ https://issues.oasis-open.org/browse/TOSCA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matthew Rutkowski  updated TOSCA-236:
-------------------------------------

       Summary: CLOSE - Mark IaaS Node Types as "substitutable" since the Orchestrator can determine impl. by default  (was: Mark IaaS Node Types as "substitutable" since the Orchestrator can determine impl. by default)
    Resolution: No longer valid, all nodes are now “selectable” can be be substituted with another topology (template).

> CLOSE - Mark IaaS Node Types as "substitutable" since the Orchestrator can determine impl. by default
> -----------------------------------------------------------------------------------------------------
>
>                 Key: TOSCA-236
>                 URL: https://issues.oasis-open.org/browse/TOSCA-236
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: New Feature
>          Components: Profile-YAML
>            Reporter: Matthew Rutkowski 
>
> In TOSCA, since we have endeavored to create a normative type system, we have always had nodes like Compute and BlockStorage that are assumed to be something that orchestrators are able to "select" an implementation for (i.e., the best impl. given the properties provided on the respective node type); in essence making them "substitutable" by design.  However, we never had a means in the grammar to indicate this until we introduced "directives" and the "substitutable" keyword value as a directive.  I propose we review our built-in types including:
> Compute:
> ObjectStorage:
> BlockStorage:
> Network:
> LoadBalancer:
> Container.Runtime
> and others...
> to see if we should add this directive to their definitions.  I believe we should since this is what the desired affect is and now we have a way to formalize this and eventually show how concrete templates can be "selected" from (perhaps from a catalog) to choose the best implementation.



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