New patchset for DCM patch: https://gerrit.onap.org/r/c/multicloud/k8s/+/110641/7

With this patchset, I am closing this story.

Kubeconfig will only be fully-done once signed user cert can be obtained from cluster/rsync. However, once it can be obtained, the change to the kubeconfig generation method will be trivial and thus I don't need this story to track it anymore. Story https://lf-akraino.atlassian.net/browse/ICN-421#icft=ICN-421 will track the completion of the user access to the logical cloud via a fully-generated kubeconfig.

New patchset for DCM patch submitted: https://gerrit.onap.org/r/c/multicloud/k8s/+/110641/6

This new patchset address point 1 and part of point 4 above.

For /kubeconfig endpoint implementation in DCM cluster reference:

• Read logical cloud user private key (reads from LogicalCloudKey)

• Read each LC/cluster's  signed cert (reads from ClusterKey)

• Read each cluster's CA cert and IP address (still unclear where or when it comes from, but this data is known by CLM)

• Build YAML kubeconfig based on all 1+N+2N elements above and other data like context and namespace name

This task actually encompasses the following tasks:

• Generate kubeconfigs for logical cloud

  • Call CLM to obtain cluster-specific data (CA cert)

• Create API to obtain kubeconfig