After updating ONAP from ElAlto to Frankfurt version I came across issue with distributed SDC artifact that blocks end-to-end workflow for CNFs. Before describing issue, let me introduce working mechanism before.

Multicloud-k8s instantiates resources defined as helm charts. As helm charts are not natively supported by SDC, these are marked as "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT" and such artifacts are downloaded by multicloud-framework-artifactbroker and uploaded via multicloud-k8s' API to be stored in internal DB. These helm charts are related one-to-one with vfModules of xNF. Because of this, artifactbroker (using common SDC library for downloading distributed content) matches helm charts based on what vf module are they linked with. That means, for CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT to be correctly onboarded by multicloud-k8s, it needs te be defined "under" specific vf-module.

The issue I've come across is, after switching to Frankfurt release, I can't see (in artifactbroker logs) helm charts available under vf-module, as only "HEAT" and "HEAT_ENV" files are (both are dummy in terms of CNFs). Previously, as far as I'm aware such matching of CLOUD...ARTIFACT to vf-module was based on prefix name. The CSAR I try to onboard didn't change between ElAlto and Frankfurt, so I think culprit must be somewhere inside SDC code.

If you need any more information from me about this issue, please tell, I'll also look more about it in next week, as so far I couldn't find relevant code section in SDC that changed and would be responsible for it. Please find attached below artifactBroker's logs (source code of broker: https://github.com/onap/multicloud-framework/tree/master/artifactbroker ) with my small logging addition, as well as raw CSAR downloaded from SDC after service design.
VF CSAR that is onboarded to SDC to be used can be found here: https://github.com/onap/demo/tree/master/heat/vFW_CNF_CDS/templates

I'll try to update this ticket with more information as I come across something relevant.