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

Need a way for resolving order for requirement processing

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: New
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Profile-YAML, Spec - Simple Profile
    • Labels:
      None
    • Proposal:
      Hide

      We might have to add another keyword in requirement definitions for defining order. For that reason, having a list of requirement definitions in node types is not important any more for preserving order, but we can move to a dictionary.

      Therefore, I would propose to make the requirement definition in node types a dictionary instead of a list. This would enforce having one key in the dictionary (i.e. one named requirement) only defined once. Furthermore, this would be slightly shorter in terms of notation and simple profile in YAML aims at being short and uncomplicated.

      Resolution of ordering is still to be resolved.

      Show
      We might have to add another keyword in requirement definitions for defining order. For that reason, having a list of requirement definitions in node types is not important any more for preserving order, but we can move to a dictionary. Therefore, I would propose to make the requirement definition in node types a dictionary instead of a list. This would enforce having one key in the dictionary (i.e. one named requirement) only defined once. Furthermore, this would be slightly shorter in terms of notation and simple profile in YAML aims at being short and uncomplicated. Resolution of ordering is still to be resolved.

      Description

      In the simple profile in YAML specification, requirement definitions are currently defined as a list. The reason was that we wanted to be able to preserve ordering, allowing a node type author to prescribe the order in which requirements in a template get processed.

      This allows for example, to make sure that operations (e.g. implemented as scripts) attached to the relationships that bind the requirements at runtime get run in the right order.

      However, we currently do not have a means for describing how requirements defined in a node type sort into the order of requirements inherited from parent node types. We cannot just assume that newly defined requirements get added to the end of the list of inherited requirements. This would mean, the generic "dependency" requirement defined by the Root node type (thus inherited by any other node type) would always be processed first, which is not desirable.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              thomas.spatzier Thomas Spatzier (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: