A cherry-pick on this one from master --> Frankfurt would be a good thing.
There is as well another possiblity - I am trying to push an approach, that we self-relese a container, for each ONAP project at each M-milestone.
This would mean, we could try to self-release at M1 beginning of July (and add this to the OOM Master repo, following all rules/regulations in that area).

Would it be something to consider here? (Gating tests should show us, that we at least haven`t messed-up something completely...)

please for information if we may have it as a Frankfurt patch. If not most probably it is implemented in master branch already.

i have seen now the code in master. And it looks it is there but in Frankfurt it is missing and we discuss about the issue in Frankfurt version. Is it possible to move this part of code to Frankfurt also?

Code is already there to write this edge, so please post a log

Hi,

Well, my view is similar here, if we decided to move the Robot HeatBridge functionality to SO-HeatBridge, then we shall be moving a complete functionality...

Generally, the VNFCs map in ONAP into the OS::Nova::Server resource name in Heat templates. If we can read, which Heat resources have been deployed as part of Heat stack instantiation, then we can as well, relatively easily find the VNFC definitions created before by SDNC, and create the necessary relations VNFC<->vserver, it doesn`t look like rocket science actually.

I am not sure, if we shall be using vserver names, as proposed before by Amir. We would be working then on an assumption, that vserver name, which can be selected arbitrary, corresponds to vnfc name. I think, it would make sense to filter out vservers, using their Heat resource name, and then use that Heat resource name as VNFC name.

Any corner cases, that I am not really aware of?