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

OPEN - CSD04 - Constraining the capabilities of multiple node templates

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: CSD1
    • Fix Version/s: CSD04
    • Component/s: Profile-YAML
    • Labels:
      None
    • Environment:

      Derek to review, see if can be updated to reflect current spec/approach/thinking.

    • Proposal:
      Hide

      Let's consider a more general use case where we want to specify the requirements for a set of node templates. Note that the node templates could be of different types which polymorphically unrelated (they are not sub/super types of each other). Nevertheless, they will have to have some common capability for the constraints to make any sense.

      To concisely express these semantics we need:
      1) A way to specify node template membership of the set of node templates we want to constrain
      2) A method for specifying the schema of the constraints
      3) A method to validate that a member can be constrained, i.e. to check if a member is a valid member or not

      node_template_requirements: # the name is not important, it's just its own section in the document

      • tosca.caps.MyCapability: # capability type we want to constrain across all members
        targets: [ node1, node2 ] # targets are the subject node templates which must support the capability
        contraints:
        secure: true
        failure_alert: true

      Each of the above requirements are now satisfied:
      1) Is satisfied by the membership list targets: [ m1, ... mn ]
      2) The constraint schema is specified with a capability type
      3) Validation is a matter of checking if each member provides the capability type

      This is one of many possible syntaxes. What's most critical is to be able to express the necessary semantics.

      Show
      Let's consider a more general use case where we want to specify the requirements for a set of node templates. Note that the node templates could be of different types which polymorphically unrelated (they are not sub/super types of each other). Nevertheless, they will have to have some common capability for the constraints to make any sense. To concisely express these semantics we need: 1) A way to specify node template membership of the set of node templates we want to constrain 2) A method for specifying the schema of the constraints 3) A method to validate that a member can be constrained, i.e. to check if a member is a valid member or not node_template_requirements: # the name is not important, it's just its own section in the document tosca.caps.MyCapability: # capability type we want to constrain across all members targets: [ node1, node2 ] # targets are the subject node templates which must support the capability contraints: secure: true failure_alert: true Each of the above requirements are now satisfied: 1) Is satisfied by the membership list targets: [ m1, ... mn ] 2) The constraint schema is specified with a capability type 3) Validation is a matter of checking if each member provides the capability type This is one of many possible syntaxes. What's most critical is to be able to express the necessary semantics.

      Description

      In section 12 Grouping Node Templates, a membership construct is used to associate scaling constraints to node template instances. This construct has the following weaknesses:
      1) The members are not constrained, i.e. the types of the members are not specified
      2) The constraints enforced on the members are not defined. I.e. there is no reference to or ability to infer a schema for the constraints

      A "type" approach which supports strong validation is more desirable. So far we have this for other aspects of the DSL so why not strive for strong validation for this construct too.

        Attachments

          Activity

            People

            • Assignee:
              dpalma Derek Palma (Inactive)
              Reporter:
              dpalma Derek Palma (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Due:
                Created:
                Updated: