[ICN-383] Evaluate "Kubeconfig API (WORK IN PROGRESS)" Created: 17/Jun/20 Updated: 17/Dec/20 Resolved: 28/Jul/20 |
|
| Status: | Done |
| Project: | Integrated Cloud Native NFV |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Story | Priority: | Medium |
| Reporter: | Igor Duarte Cardoso | Assignee: | Igor Duarte Cardoso |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Epic Link: | DCM dev works |
| Sprint: | ICN Sprint 20, ICN Sprint 21, ICN Sprint 22 |
| Story Points: | 1 |
| Description |
|
In https://wiki.onap.org/pages/viewpage.action?pageId=76875956, it is claimed Kubeconfig API is a work in progress. Investigate what is the status of this and prepare next steps. |
| Comments |
| Comment by Igor Duarte Cardoso [ 28/Jul/20 ] |
|
The conclusion is that this API (for obtaining the kubeconfig of a cluster of a logical cloud directly from dcm) is not implemented at all. rsync will get the kubeconfig from dcm, which is enough to get the logical resources installed in each cluster. However, a different kubeconfig needs to be created so that it can be handed to the owners of the logical clouds. This is why we need this specific kubeconfig API in dcm itself. A different task should be created in the future in order to implement a custom kubeconfig (with the right user, permissions, etc) per cluster in logical cloud. Closing story. |