-
Story
-
Resolution: Done
-
High
-
None
Support the substitution_mappings in the VNFD.
Currently, the substitution_mappings is not supported by SDC. Lack of this support blocks SOL004 VNF package management and ETSI Catalog Manager:
- Prior to Frankfurt, as a workaround, the operator creates a dummy VNF without the substitution_mappings or node_types in the MainServiceTemplate.yaml and added a real VNF package with the substitution_mappings and user-define nodes in its Artifacts>DEPLOYMENT>OTHER directory.
- It is to trick the current SDC onboarding issues because SDC does not check the OTHER directory.
- In the Frankfurt/Dublin release, SDC was enhanced to support the vendor VNF package in the ONBOARDED_PACKAGE directory.
- In the Guilin release, the ONBOARDED_PACKAGE directory is changed to the ETSI_PACKAGE.
- Since SDC Frankfurt/Dublin, we don't have to use the secondary VNF package unnecessary, but we still needs to follow an old way because of lack of substitution_mappings and user-defined node_types.
- When SDC supports the subscription_mappings user-defined node types, the vendor VNF package does not have to add another VNF package in the Artifacts>DEPLOYMENT>OTHER directory, and the ETSI Catalog Manager will support the VNF package in the ETSI_PACKAGE directory.
- ETSI Catalog Manager will depend on this SDC support.
Support of the substitution_mappings and user-defined node_types will remove the issues and support ETSI package management and others.
Support of the user-defined node types is handled by another task. This task needs to handle the substitution_mappings only.
For the testing, use the vgw6.csar
For the Frankfurt release workaround, we added the following to the MainServiceTemplate.yaml, so the ETSI Catalog Manager can retrieve the descriptor_id from the metadata, instead of from the node_type. Once the substitution_mapping is supported by SDC, we don't have to use the descriptor_id in the metadata section.
- descriptor_id: b1bb0ce7-2222-4fa7-95ed-4840d70a1177
- mentioned in
-
Page Loading...