Context:

SO-1450 ticket introduced communication with MSB via https schema. It may be that also some other ticket impacted the fact, that currently, Multicloud endpoint determined by SO is

2020-04-16T17:30:37.953Z|6a713554-aa6b-473b-8065-0a65bf5d6ede|org.onap.so.openstack.utils.MsoMulticloudUtils - Multicloud Endpoint is: https://msb-iag.onap:443/api/multicloud/v1/     k8scloudowner4/k8sregionfour/infra_workload?name=Demo-58-base_template

What's critical here, is that we can see single "v1" in multicloud path. As you can see in ticket MULTICLOUD-820, multicloud-k8s's URL via MSB has double /v1/. Fixing this would also require aligning robot health check to comply with new URL.
One more issue is that such request (/api/multicloud/v1/k8scloudowner4/...) would be forwarded to "/v1/k8scloudowner4/..." URL in k8splugin, that currently is defined (for this concrete endpoint) to listen on URL without preceding "/v1/". This doesn't conform to Multicloud API specification (https://docs.onap.org/en/dublin/submodules/multicloud/framework.git/docs/MultiCloud-APIv1-Specification.html), however it worked for ElAlto, as probably SO call was formated differently.

In order to fix this bug I propose to fix:

• K8splugin's "/{}/{}/infra_workload" API to listen with preceeding /v1/
• K8splugin's MSB service definition to remove duplicated /v1/
  • To comply with this change also update robot test to query correct URL

This will fix the issue, however End2End instantiation still wouldn't work without workaround until MSB-467 is fixed as it makes SO fail on improper certificate during MSB call.

I think I don't miss any action that needs to be done here, if I do, please comment.

Due to the nature of these fixes, they are all in different repositories and interact with each other, so that they need to be synchronized to minimize cross-ONAP (mostly CI) impact