[RFE] oc CLI should preserve name of contexts

[jorgemoralespou]

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:

• kubectl UX: make it easy to switch namespaces kubernetes/kubernetes#40968

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.

[jwforres]

@openshift/sig-master

[juanvallejo]

There is a related discussion about context management here: #16161 (comment)

cc @liggitt for thoughts on this

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[jorgemoralespou]

/lifecycle frozen

[jorgemoralespou]

@juanvallejo any update on this? This problem causes issues also in minishift minishift/minishift#2871

[juanvallejo]

@jorgemoralespou As far as I can tell, this is not something that is being actively worked on. Existing oc commands, such as oc project depend on the current context-naming scheme (default/console-cluster02-gce-pixy-io:8443/admin).

I think broader agreement would have to be reached on this change first, as it would involve changes across multiple parts of oc.

cc @deads2k

[jorgemoralespou]

@juanvallejo, maybe since we're looking at v4 this is a change we could accomplish and finally fix this long-standing bad behavior.
cc/ @smarterclayton

[soltysh]

@jorgemoralespou the usability problems you're raising are fair and I think we should solve them, but I doubt the sheer volume of work around v4 will allow us to invest any time into oc, and I'm speaking as the owner of that component.

[jorgemoralespou]

Does this mean a won't fix? From what understood in previous conversations this could only be looked if we ever went through a major release. This is the first in 3 years, and I don't expect another one sooner than that.
Is this something that could be fixed in minor releases? Meaning 4.1, or 4.2, or it won't happen at least until 5.0?

[soltysh]

Does this mean a won't fix?

Nope, I didn't say that. What I said is that it won't happen for 4.0, but I'm not saying it can't nor it shouldn't be fixed in following releases. I don't see this being a breaking change, so it can be done at any point in time. Not sure who told you otherwise.

[jorgemoralespou]

@smarterclsyton and liggit

[erszcz]

Looking forward to this happening 🤞

[thanosz]

Hello, any chance this gets revisited? @soltysh