Uploaded image for project: 'OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC'
  1. OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
  2. TOSCA-229

Requirements / target filters and subsituable / selectable are too confusing.

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Proposal:
      Hide

      So in my opinion we should:

      • Move target_filters to the node type's requirement section as it make sense here: I create a reusable implementation of a MySQL that is based on sh scripts so I want to be able to specify the host requirement to specify that the os type is linux.
      • Remove target_filters from the node templates requirement section.
      • Remove the directives and keep only an abstract keyword that is false by default (or substitutable if abstract is not clear enough). I don't seen the need for directives right now, a single substitutable seems to do the job and is quite simpler in my opinion.
      • Make Compute node abstract (or substituable) - same as block storage or other IaaS components.
        Note that a type may be abstract too and not just a node template. I don't see the scenario of a Compute node that is not selectable somehow as this is instantiated on the cloud... For me Compute node is by definition an abstract node that is substitutable and the orchestrator should find a valid match to instantiate a VM with the right required contraints or find a real machine if bare-metal is supported by the orchestrator.
      • Use the substitution mechanism for both substitution and selectable in a topology. The orchestrator implementation is responsible for providing the valid mechanisms to put in front.

      At the end that leaves the TOSCA user with only 2 notions and use cases which is much simpler to explain and understand and leaves also in my opinion more flexibility both to users and implementors.

      • On a type - or substituable type (that defines a reusable entity) I can specify requirements with target_filters to make sure that when someone reuse my entity it will be a compliant usage based on my nodes real requirements.
      • In a topology template every node that the orchestrator must provide (by offering selection or automatic best-match or both – specific to implementation and vendor) must be defined as an abstract (or substitutable) node.

      PS: I'm really sorry I was not able to make it to the tuesday call as I know I come a bit late with my points but still hope this is makes sense for you too.

      Show
      So in my opinion we should: Move target_filters to the node type's requirement section as it make sense here: I create a reusable implementation of a MySQL that is based on sh scripts so I want to be able to specify the host requirement to specify that the os type is linux. Remove target_filters from the node templates requirement section. Remove the directives and keep only an abstract keyword that is false by default (or substitutable if abstract is not clear enough). I don't seen the need for directives right now, a single substitutable seems to do the job and is quite simpler in my opinion. Make Compute node abstract (or substituable) - same as block storage or other IaaS components. Note that a type may be abstract too and not just a node template. I don't see the scenario of a Compute node that is not selectable somehow as this is instantiated on the cloud... For me Compute node is by definition an abstract node that is substitutable and the orchestrator should find a valid match to instantiate a VM with the right required contraints or find a real machine if bare-metal is supported by the orchestrator. Use the substitution mechanism for both substitution and selectable in a topology. The orchestrator implementation is responsible for providing the valid mechanisms to put in front. At the end that leaves the TOSCA user with only 2 notions and use cases which is much simpler to explain and understand and leaves also in my opinion more flexibility both to users and implementors. On a type - or substituable type (that defines a reusable entity) I can specify requirements with target_filters to make sure that when someone reuse my entity it will be a compliant usage based on my nodes real requirements. In a topology template every node that the orchestrator must provide (by offering selection or automatic best-match or both – specific to implementation and vendor) must be defined as an abstract (or substitutable) node. PS: I'm really sorry I was not able to make it to the tuesday call as I know I come a bit late with my points but still hope this is makes sense for you too.

      Description

      There is too many notions in the requirements management in the current simple profile document. This makes things very hard to follow while there is actually in my opinion not that many notions to be defined.

      Target filter makes no sense in my opinion in their current placement (on the node template requirements) as they are duplicated with the selectable directive.

      I think it would be more consistent to use the 'selectable' directive in every situations rather than relying on target_filter.
      I also think that selectable pattern is also exactly the same as substitutable from a user perspective as this answer a single need:

      • I want to link some components to a node that is abstract and I rely on the orchestrator tool to provide a node that match my requirement.
        The fact that the orchestrator provides a selectable or automatic (substitutable) matching (or both with a best-match) is a tool feature and has no place in the specification in my opinion. The matching and quality of matching feature and presentation of the feature is implementor specific.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              luc.boutier Luc Boutier (Inactive)
            • Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: