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:
VF CSAR:
SERVICE CSAR:
23 Comments
Manoj Nair
Hi Michael,
Couple of queries on the structure here
Michael Lando
[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.]
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?.
Please help me to package the CSAR with VNF image. Thanks
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.
Karthikeyan Dhandapani
Thanks for your quick response.
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.
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
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:
Second trial:
what's the arrangement should be?
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.
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
does not work.
Michael Lando
please send me your csar example so i can take a look.
libo zhu
have sent it to you. pls help and have a check
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?
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.
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..
Bogumil Zebek
Jennie Jia Any update? I also tried to deploy mentioned csar file and I have similar error :/
Zu Qiang (Ericsson)
@Michael Lando, Questions:
Brian Freeman
CSARs need to be updated for latest Casablanca Release
Susan Mangini
Are there any new CSAR sample files available for Casablanca?
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
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'.
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.
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.