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