Description
When working with OpenShift, it might happen that you connect to multiple clusters. These can be cloud clusters, on-premises, or even multiple profiles of minishift.
When you connect to a cluster, oc creates an entry for that context including cluster, user and namespace. These contexts that are created are given an automatic name by oc.
e.g.
default/console-cluster02-gce-pixy-io:8443/admin
default/127-0-0-1:8443/system:admin
devconfcz18/api-pro-us-east-1-openshift-com:443/[email protected]
These names are difficult to handle and remember.
Kubernetes does promote giving these contexts a meaningful name in their documentation. But when you follow those practices in OpenShift, you run into many issues, which are what this issue/RFE wants to solve.
- Login into an openshift cluster via "oc login" creates entries in .kube/config even if they exist with different name
- "oc new-project" creates entries in .kube/config even if they exist with different name instead of just changing the current context's namespace
- "oc project" creates entries in .kube/config even if they exist with different name instead of just changing the current context's namespace
- "oc delete project" does not remove the namespace from the current context's context (or set a default)
- "oc logout" does not unset the "current-context" but only remove the token.
There's probably other things that make "oc" misbehave with respect to keeping a sane .kube/config file.
There's references in k8s to make enhancements on the usability:
As well as references in other projects of the problem I described:
- Running minishift delete followed by minishift start leaves invalid entries in .kube/config minishift/minishift#1915
- Meaningful/Custom Context Names for oc minishift/minishift#1917
This RFE is to fix the behavior the "oc" client has with respect to using/interacting with .kube/config file.