origin
origin copied to clipboard
openshift
[RFE] oc CLI should preserve name of contexts
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:
- https://github.com/kubernetes/kubernetes/issues/40968
As well as references in other projects of the problem I described:
- https://github.com/minishift/minishift/issues/1915
- https://github.com/minishift/minishift/issues/1917
This RFE is to fix the behavior the "oc" client has with respect to using/interacting with .kube/config file.
There is a related discussion about context management here: https://github.com/openshift/origin/pull/16161#issuecomment-328577474
cc @liggitt for thoughts on this
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
@juanvallejo any update on this? This problem causes issues also in minishift https://github.com/minishift/minishift/issues/2871
@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
@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
@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.
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?
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.
