the SDC CSAR structure is separated into 3 phases:


CSAR provided by the vendor to the SDC for onboarding:

this is the currently expected structure supported by SDC


ROOT\

MainServiceTemplate.mf [a map representing the different parts of the CSAR structure.]

MainServiceTemplate.yaml [copy of the main service template located under Defanitions]

\TOSCA-Metadata\

TOSCA.meta [ metadata regarding the CSAR structure]

\Artifacts\  [includes all artifacts.]

Images are not supported.

Artifact type will be identified by an additional folder under “Informational”/“Deployment” that will define the artifact type SDC supported artifact types can be found here: SDC supported artifact types.

Artifacts at the root directory or unrecognized folder(s) will be classified as type “Other” 

\Informational\  [will hold all informative artifacts in the direct asset level]

\Deployment\ [Sub-folder directly under “Artifacts”– Deployment artifacts in the direct asset level] 

\<VFC  TOSCA name>\ 

\Informational\ [will hold all informative artifacts on VFC level ] 
\Deployment\ [will hold all deployment artifacts on VFC level  ]

\Definitions\  [includes all TOSCA yaml files ]



CSAR created by SDC for VF:

ROOT\

\TOSCA-Metadata\

TOSCA.meta [ metadata regarding the CSAR structure]

\Artifacts\  [includes all artifacts.]

Artifact type will be identified by an additional folder under “Informational”/“Deployment” that will define the artifact type SDC supported artifact types can be found here: SDC supported artifact types.

Artifacts at the root directory or unrecognized folder(s) will be classified as type “Other” 

\Informational\  [will hold all informative artifacts in the direct asset level]

\Deployment\ [Sub-folder directly under “Artifacts”– Deployment artifacts in the direct asset level] 

\<VFC  TOSCA name>\ 

\Informational\ [will hold all informative artifacts on VFC level ] 
\Deployment\ [will hold all deployment artifacts on VFC level  ]

\Resources\

\<node_template name>\  [per each node_template that has specific artifacts (artifacts that were added to the instance / customized for the instance or generated for the instance).
This folder should NOT include artifacts of the type of the instance (e.g. HEAT should be in the folder of the VF and not in the folder of the VF instance, HEAT_ENV will be in the folder of the instance)]

\Definitions\  [includes all TOSCA yaml files ]



CSAR created by SDC for SERVICE:

ROOT\

\TOSCA-Metadata\

TOSCA.meta [ metadata regarding the CSAR structure]

\Artifacts\  [includes all artifacts.]

Artifact type will be identified by an additional folder under “Informational”/“Deployment” that will define the artifact type SDC supported artifact types can be found here: SDC supported artifact types.

Artifacts at the root directory or unrecognized folder(s) will be classified as type “Other” 

\Informational\  [will hold all informative artifacts in the direct asset level]

\Deployment\ [Sub-folder directly under “Artifacts”– Deployment artifacts in the direct asset level] 

\<VF TOSCA name>\ 

\Informational\ [will hold all informative artifacts on VF level ] 
\Deployment\ [will hold all deployment artifacts on VF level  ]

\Resources\

\<node_template name>\  [per each node_template that has specific artifacts (artifacts that were added to the instance / customized for the instance or generated for the instance). 
This folder should NOT include artifacts of the type of the instance (e.g. HEAT should be in the folder of the VF and not in the folder of the VF instance, HEAT_ENV will be in the folder of the instance)]

        \Deployment\

                 \BPMN\ [Includes all workflow BPMN artifact files]

\Definitions\  [includes all TOSCA yaml files ]


CSAR examples:

vendor CSAR:

vCSCF.csar

VF CSAR:

resource-Vcpeinfra09-csar.csar

SERVICE CSAR:

service-Demovlb-csar.csar


23 Comments

  1. Manoj Nair

    Hi Michael, 

    Couple of queries on the structure here 

    • Which are the mandatory information in "CSAR provided by the vendor to the SDC for onboarding" . Assuming all the folders/files under ROOT are mandatory except for the Artifacts. 
    • Regarding "Artifacts at the root directory or unrecognized folder(s) will be classified as type “Other” " . This means artifacts need not be placed under Artifacts, it can be loosely placed in the root directory.
    • Can you please clarify if any validation is done inside SDC to check the Artifact Type to Artifact file name extension. 
    • As we understand from above - Following is typical structure . Kindly confirm
      • Root 
        • TOSCA-MetaData
        • Artifacts 
          • Informational
          • Deployment 
            • HEAT
              • Heat File 1
              • Heat File 2
            • HEAT_ENV
              • Heat_Env1
              • Heat_Env2
        • Definitions
          • TOSCA YAML 1
          • TOSCA YAML 2
    • Can you please clarify the typical artifacts placed in Informational and Deployment subfolders ? Is there any restrictions from SDC side on the placement of specific type of artifact in specific folders in CSAR (Informational/Deployment) 
    • Can you please let us know where we can see a sample CSAR for the 3 cases mentioned above ? 



  2. Michael Lando

    • Which are the mandatory information in "CSAR provided by the vendor to the SDC for onboarding" . Assuming all the folders/files under ROOT are mandatory except for the Artifacts. [Michael: Correct]
    • Regarding "Artifacts at the root directory or unrecognized folder(s) will be classified as type “Other” " . This means artifacts need not be placed under Artifacts, it can be loosely placed in the root directory. [Michael: artifacts need to be placed in the artifact folder]
    • Can you please clarify if any validation is done inside SDC to check the Artifact Type to Artifact file name extension. 
      [Michael: we perform validation to specific artifact types. The expected format is part of the artifact types document SDC supported artifact types. When we specify the format we expect – we also do basic validation to it. However, for other artifact types we don’t perform the validation.]
    • As we understand from above - Following is typical structure . Kindly confirm [Michael: correct]
    • Can you please clarify the typical artifacts placed in Informational and Deployment subfolders ? Is there any restrictions from SDC side on the placement of specific type of artifact in specific folders in CSAR (Informational/Deployment) [Michael: Currently in the Informational folder we allow all artifact types (even if they are considered as deployment, so someone can keep himself an old heat for reference). However, in the Deployment folder we don’t allow types that are considered “Informational” (such as “GUIDE”). ]
    • Can you please let us know where we can see a sample CSAR for the 3 cases mentioned above ? [Michael: I am attaching examples to the wiki here ]


  3. Karthikeyan Dhandapani

    Hi @Michael Lando ,

    I am trying to create csar package with TOSCA template. In the specified CSAR Structure, If Artifacts folder does not support image, then where should I keep my image file?.

    1. I created image folder and specified the path in the Manifest file, but It did not work. The Error in SDC is "Upload Validation Failed".
    2. If I upload the csar package without image, It is not showing any error.

    Please help me to package the CSAR with VNF image. Thanks




    1. Michael Lando

      the image uploading as part of the csar is not sported at the moment. such a requirement exists in our back log and is being discussed.

      at the moment as far as i know the images are pulled by so during or castration.

      1. Karthikeyan Dhandapani

        Thanks for your quick response. 

      2. Karthikeyan Dhandapani

        Hi Michael, I have one Quick question.

        If the image is pullled by SO in the sense ,  Either from giving image url or will it take from Glance ? . Please clarify

        Thanks.

  4. kowsalya v

    Is there any sample VFC tosca csar are available? I am getting invalid resource namespace for the below tosca template.


    template_name: tosca-db
    template_author: TOSCA TC
    template_version: 1.0.0.wd03-SNAPSHOT

    node_types:
    SqlDatabase:
    derived_from: tosca.nodes.Root
    abstract: true
    description: test.
    attributes:
    tosca_id:
    type: string
    tosca_name:
    type: string

  5. libo zhu

    @Michael Lando, for the "Artifacts at the root directory or unrecognized folder(s) will be classified as type “Other” ", we've tried below two ways, both of them will be removed automatically by SDC after generate the service.

    First trial:

    • Artifacts
    •  Deployment
      • Other
        • authorized_keys #File 1
        • ubuntu16.04 #File 2


    Second trial:

    • Artifacts
      •  images
        • ubuntu16.04 #File
      •  keys 
        • authorized_keys #File
        • id_rsa #File
        •  id_rsa.pub #File


    what's the arrangement should be? 

    1. Michael Lando

      just so that I am clear. can you be more specific about what you tried and how?

      we have usually a number of options to add artifacts, you can do it from the onboarding package or from the user interface.


      from what I see in your example you are trying to upload images this is not supported at all.

      sdc will not except such big files since we cannot handle them.

      1. libo zhu

        hello, Michael,

                      i understand and  it does make sense to UN-support upload images. 

                     and i understand user could add Other type of SDC supported types by UI/Portal.

                     my question is that is it possible to add the keys in above structure into input csar file? let's ignore the images dir. if i want to add authorized_keys in the input csar file, is it possible to put it into Artifact subdir? if so, then what's the placement should be?

        Artifacts

        •  Deployment
          • Other
            • authorized_keys #File 1

        does not work. 

  6. Michael Lando

    please send me your csar example so i can take a look.

    1. libo zhu

      have sent it to you. pls help and have a check

  7. Jennie Jia

    Hi Michael,

    which release of the SDC Portal you use for the Vendor CSAR testing ?  I want create VSP using Vendor CSAR, I have latest Casablanca OOM code (last week). when I upload the vCSCF.csar. I got the UI "UPLOAD VALIDATION FAILED.. ERROR: Manifest must contain Source". 

    Also what is the guide line  if I want create my own vendor TOSCA CASR file? by following the CSAR Structure? and anything else?


    1. udhaya chandran

      Hi Jennie Jia,

      The latest code of SDC (Master branch) for validating the MainServiceTemplate.mf file has been aligned as per SOL004.

      The "source" in MainServiceTemplate.mf has to be changed as "Source". 

      vCSCF.csar doesn't align to this change.

      Michael Lando,  In vCSCF.csar, MainServiceTemplate.mf has to be updated.

      1. Jennie Jia

        Hi udhaya chandran,

        I updated the MainServiceTemplate.mf by change to "Source" and repackage to zip/csar and tried again, this time I got "INTERNAL_SERVER_ERROR" WITH ErrorID: TGIQNWTW... no idea..need do more debug..


        1. Bogumil Zebek

          Jennie Jia Any update? I also tried to deploy mentioned csar file and I have similar error :/

  8. Zu Qiang (Ericsson)

    @Michael Lando,  Questions:

    • Is this typical Artifacts structure a must for vendor provided package? If yes, any plan to update it?
    • Is this typical Artifacts structure for Heat model only, or applied for SOL001 TOSCA as well?

  9. Brian Freeman

    CSARs need to be updated for latest Casablanca Release

  10. Susan Mangini

    Are there any new CSAR sample files available for Casablanca?

  11. Brian Freeman

    service-Demovfwvcpeinfra-csar.csarservice-Demovfwvcpevbng-csar.csarservice-Demovfwvcpevbrgemu-csar.csarservice-Demovfwvcpevgmux-csar.csarservice-Demovfwvcpevgw-csar.csarservice-Demovfwvfwcl-csar.csarservice-Demovfwvlb-csar.csarservice-Vcperescust2018122620181226060458352-csar.csarservice-Vfw20181219052258-csar.csarservice-Vfwng201812200542-csar.csar

  12. Susan Mangini

    Thank you so much for answering and providing these. I should have been more specific.  While these appear to be CSARs created by SDC,  I would like to look at the VSP flow in SDC, therefore need a 'CSAR provided by the vendor to the SDC for onboardiing'. 

     

  13. Chris Lauwers

    I know I'm coming in late into this discussion, but I wonder why for Phase 1 (onboarding CSARs into SDC) we want to impose a "standard" CSAR directory structure at all? Standard TOSCA doesn't do this. Instead, the expectation in TOSCA is that the CSAR is "self-describing" using the TOSCA meta file (which is the only file that needs to be in a well-defined location). Wouldn't the benefit of allowing any TOSCA-compliant CSAR file to be onboarded outweigh the benefits of simplifying CSAR processing by SDC? Alternatively, if there are any SDC features that require knowledge about the CSAR structure that cannot be obtained from the TOSCA meta file (or from the service templates themselves), wouldn't we want to suggest extensions to the TOSCA meta file rather than imposing an ONAP-proprietary CSAR structure? Of course, for any internally-distributed CSAR files, it's OK to mandate whatever CSAR structure is most convenient.

  14. Zu Qiang (Ericsson)

    Hello Chris Lauwers 

         I would agree with you that Standard TOSCA is "self-describing" using the TOSCA meta file. However, SDC does not support Standard TOSCA at this moment, not only on-boarding csar package, but also internal csar package. In Dublin release, there is working item, named 5G - PNF Pre-Onboarding & Onboarding, which we try to find a way to modify the existing SDC in order to support standard TOSCA for on-boarding.