Details

    • Type: New Feature
    • Status: New
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: CSD03
    • Component/s: Profile-YAML
    • Labels:
      None
    • Proposal:
      Hide

      I am proposing two options for the discussion and would love to hear more.

      Examples of both options are available in the working document https://www.oasis-open.org/apps/org/workgroup/tosca/document.php?document_id=53454

      Option-1 (Preferred by me)
      The first option consists on TOSCA standards with additional root keynames "repositories" and "repository_types" to describe external repositories (see option-1.zip).
      The same as any TOSCA element, these elements can reside within the same service template file or can also be extracted to an additional dedicated file (e.g. option1-repositories.yaml.ste) in order to keep it decoupled from the rest of the service template.
      Each repository element will contain a list of the artifacts it holds.

      Pros:
      • Reuse existing parsing mechanism.
      • Reuse existing inputs mechanism.
      • Does not break current TOSCA implementation: repositories implementation is decoupled.
      (Node-template artifacts are searched by key in repository artifacts)

      Cons:
      • The repositories info does not really belong to the service template as it is more related to the env the application is deployed on (We tried to address this issue by placing the "repositories" section in a separate file and making the reference from the repository to the artifact instead of from the artifact to its repository).

      Option-2
      The second option uses an archive’s MANIFEST.MF file to describe deployment’s external repositories (see MANIFEST.MF). While this alternative does not break TOSCA implementation (see option2.yaml.ste) it does makes an abnormal use of MANIFEST.MF file which meant to describe an archive contents only. MANIFEST.MF also forces its own syntax and is not flexible as yaml is.
      Generating MANIFEST.MF file is most likely automated and additional properties will either need to be added manually or by a dedicated framework.

      Pros:
      • Very clear decoupling of repositories from TOSCA service template.
      • One central place to describe all of an application artifacts.

      Cons:
      • Abnormal use of MANIFEST.MF file.
      • Dedicated MANIFEST.MF parser (on top of java.util.jar.Manifest) is required.
      • Dedicated inputs mechanism will need to be developed.

      Show
      I am proposing two options for the discussion and would love to hear more. Examples of both options are available in the working document https://www.oasis-open.org/apps/org/workgroup/tosca/document.php?document_id=53454 Option-1 (Preferred by me) The first option consists on TOSCA standards with additional root keynames "repositories" and "repository_types" to describe external repositories (see option-1.zip). The same as any TOSCA element, these elements can reside within the same service template file or can also be extracted to an additional dedicated file (e.g. option1-repositories.yaml.ste) in order to keep it decoupled from the rest of the service template. Each repository element will contain a list of the artifacts it holds. Pros: • Reuse existing parsing mechanism. • Reuse existing inputs mechanism. • Does not break current TOSCA implementation: repositories implementation is decoupled. (Node-template artifacts are searched by key in repository artifacts) Cons: • The repositories info does not really belong to the service template as it is more related to the env the application is deployed on (We tried to address this issue by placing the "repositories" section in a separate file and making the reference from the repository to the artifact instead of from the artifact to its repository). Option-2 The second option uses an archive’s MANIFEST.MF file to describe deployment’s external repositories (see MANIFEST.MF). While this alternative does not break TOSCA implementation (see option2.yaml.ste) it does makes an abnormal use of MANIFEST.MF file which meant to describe an archive contents only. MANIFEST.MF also forces its own syntax and is not flexible as yaml is. Generating MANIFEST.MF file is most likely automated and additional properties will either need to be added manually or by a dedicated framework. Pros: • Very clear decoupling of repositories from TOSCA service template. • One central place to describe all of an application artifacts. Cons: • Abnormal use of MANIFEST.MF file. • Dedicated MANIFEST.MF parser (on top of java.util.jar.Manifest) is required. • Dedicated inputs mechanism will need to be developed.

      Description

      Currently, the DSL supports two types of artifacts locations:
      1. In the CSAR - the artifact URI is relative to the location in the CSAR file.
      2. In an external repository - the artifact URI is a public URL to some file server.
      The file server can require credentials that can be supplied in the URL in the format "protocol://username:password@hostname/" but because we don't have concatenation functions in the DSL, we can't use get_input and the username and password will need to be "hard-coded" inside the template.

      There is a concrete need for an external repository as the size of the deployments artifacts can sometimes reach several GBs and there is a requirement from customers that the repository should be secured.

        Attachments

          Activity

            People

            • Assignee:
              mrutkows Matthew Rutkowski
              Reporter:
              MosheElisha Moshe Elisha (Inactive)
            • Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: