...
- Node type for ASD and data type for the deployment items added to Definitions/nodes.yaml and Definitions/data.yaml respectively
- interface type (i.e. the substitution mapping type) created from org.openecomp.resource.abstract.nodes.VF, in standard ONAP way, with the standard ONAP properties
- Main template generated as follows:
- node template added for the ASD type generated from the definition in the onboarded csar
- vfModule group type added for each deployment item. see below for explanation of the properties and values used
extend thelifecycl parametersorg.openecomp.groups.VfModule
to hold the DeploymentItems properties, such as deployment_order andlifecycle parameters.//note: SO CNFM can read the DeploymentItems attributes including priorities for orchestration.- sub. mapping added in standard ONAP way
- Helm charts added to Artifacts/Deployment/HELM (similar to what is done today for onap zip cnf packages)
- Original onboarded ASD csar is included in the same way as we do for ETSI.
- Can we add anything specific to allow SO identify the package as ASD?; it could be done by SO deducing from the info already there (e.g. does it have a node template of the ASD type), but will be straightforward to add something explicitly if that is preferred, similar to what we have suggested in the TOSCA.meta
- We need a way for SDC to recognise the onboarded csar as an ASD, for etsi we reply on presence of ETSI-... metdata. We can add something similar for ASD
- we can use ASD-specific metadata the main manifest file
- we can use the TOSCA.metadata model type flag
...
file | types | Comments |
---|---|---|
data.yaml |
| |
| TBD | |
| TBD | |
nodes.yaml |
| |
resource-<asd>-template.yml |
|
e.g., deployment_order
|
...