Hi All, I am trying to test the VNFM integration flow explained in below post using ONAP Guilin release (instead of Dublin release).
https://wiki.onap.org/pages/viewpage.action?pageId=68524128 ( https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.onap.org%2Fpages%2Fviewpage.action%3FpageId%3D68524128&data=04%7C01%7Cvikas.kapoor%40infosys.com%7Cc9b0010d2fc146ff714c08d941cecbc0%7C63ce7d592f3e42cda8ccbe764cff5eb6%7C0%7C0%7C637613178695421904%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nkl%2F33Xl6L1tAdBi%2FLPBp1UBOAJLUCobZqJKhEltzaI%3D&reserved=0 ) I encountered multiple challenges and able to resolve some of them; and would like to validate the workarounds opted by me in this forum. * The VNFM Adapter in SO was correctly invoked after the workflow in SO catalogdb has been patched to invoke tsiVnfInstantiateBB step. The VNFM adapter is pulling the registered SVNFM details from AAI but it fails to pull VNFD package from the ETSI Catalog through MSB. On further investigation, I found that the VNFD package is not getting ingested into ETSI Catalog by SDC as expected. The DMaaP registration is disabled by default in ETSI Catalog configuration in modeling Helm chart and hence it is not getting notifications for VNFD package being distributed. I could make it work by enabling this DMaaP registration and some other minor fixes. *Why is DMaaP disabled by default in ETSI Catalog; is it not planned to be utilized as the package manager for SOL00X adapters of SO?* * After ETSI Adapter fix, the VNFM Adapter was able to pull VNFD package via ETSI Catalog. However, it started throwing following exception while trying to extract descriptor id from the TOSCA template in VNFD package. Unable to extract descriptor_id from ONAP package] with root cause java.lang.RuntimeException: Missing child node_types at org.onap.so.adapters.etsisol003adapter.lcm.NvfmAdapterUtils.abortOperation(NvfmAdapterUtils.java:62) at org.onap.so.adapters.etsisol003adapter.lcm.NvfmAdapterUtils.childElement(NvfmAdapterUtils.java:40) at org.onap.so.adapters.etsisol003adapter.lcm.NvfmAdapterUtils.child(NvfmAdapterUtils.java:34) at org.onap.so.adapters.etsisol003adapter.lcm.extclients.EtsiPackageProvider.getValueFromNodeTypeDefinition(EtsiPackageProvider.java:100) at org.onap.so.adapters.etsisol003adapter.lcm.extclients.EtsiPackageProvider.getVnfNodeProperty(EtsiPackageProvider.java:87) at org.onap.so.adapters.etsisol003adapter.lcm.extclients.EtsiPackageProvider.getVnfdId(EtsiPackageProvider.java:62) On further investigation, I found that the VNFD parsing logic in EtsiPackageProvider class is expecting node_types element in TOSCA template yaml but is not expanding various other base yaml files included using imports statement; for example imports: - nodes: file: nodes.yml - datatypes: file: data.yml - capabilities: file: capabilities.yml Usually various derived node types would be defined in these base yaml files under node_types element. I believe this is defect and needs to be fixed. As a workaround, I used a VNF package with just a single VNF element in TOSCA template to circumvent this check. *Kindly verify if I should log a bug for this issue and under which project?* Thanks & Regards Girish -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#23376): https://lists.onap.org/g/onap-discuss/message/23376 Mute This Topic: https://lists.onap.org/mt/84061949/21656 Mute #vnfm:https://lists.onap.org/g/onap-discuss/mutehashtag/vnfm Mute #so:https://lists.onap.org/g/onap-discuss/mutehashtag/so Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
