XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: CSD03
    • Fix Version/s: None
    • Component/s: Spec
    • Labels:
      None
    • Proposal:
      Hide

      In cases in which a CSAR packages multiple <ServiceTemplate> elements the existence of a Entry-Service-Template field allows an efficient processing of the <ServiceTemplate> elements: By being pointed to the main service template the contained imports can immediately be resolved. Without the Entry-Service-Template field, all of the N contained <ServiceTemplate> elements must be inspected and analyzed, some sort of dependency graph must be build, and the "main service template" (i.e. the entry to the set of N service templates) must be identified. For large numbers of N, this is inefficient.

      Thus, for CSARs that contain <ServiceTemplate> elements it should be possible to set the value of Entry-Service-Template field. For CSARs that do not include <ServiceTemplate> element setting a value for the Entry-Service-Template field is not meaningful. As a consequence, the Entry-Service-Template field should be made OPTIONAL.

      Show
      In cases in which a CSAR packages multiple <ServiceTemplate> elements the existence of a Entry-Service-Template field allows an efficient processing of the <ServiceTemplate> elements: By being pointed to the main service template the contained imports can immediately be resolved. Without the Entry-Service-Template field, all of the N contained <ServiceTemplate> elements must be inspected and analyzed, some sort of dependency graph must be build, and the "main service template" (i.e. the entry to the set of N service templates) must be identified. For large numbers of N, this is inefficient. Thus, for CSARs that contain <ServiceTemplate> elements it should be possible to set the value of Entry-Service-Template field. For CSARs that do not include <ServiceTemplate> element setting a value for the Entry-Service-Template field is not meaningful. As a consequence, the Entry-Service-Template field should be made OPTIONAL.
    • Resolution:
      Hide

      Simply re-introduce the Entry-Service-Template field by copying the corresponding text from WD-12 back into the spec. Next, define this field as OPTIONAL.

      Show
      Simply re-introduce the Entry-Service-Template field by copying the corresponding text from WD-12 back into the spec. Next, define this field as OPTIONAL.

      Description

      Until WD-12 the Block_0 of a CSAR contained the Entry-Service-Template field. WD-13 removed this field, basically because the newly introduced <Definition> files do not necessarily contain a <ServiceTemplate> element at all to support modular definition and reuse of other TOSCA entities. Thus, the Entry-Service-Template field does not make any sense for a CSAR that does not package a <ServiceTemplate> element at all.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              leymann Frank Leymann (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: