-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API Resources "carry over" between contexts, causing errors if they share shortnames #2492
Comments
Merged
@djpenka Great catch! Thank you for this awesome bug report Dylan. |
Merged
thejoeejoee
pushed a commit
to thejoeejoee/k9s
that referenced
this issue
Feb 23, 2024
placintaalexandru
pushed a commit
to placintaalexandru/k9s
that referenced
this issue
Apr 3, 2024
Hey there, first of all, thanks for k9s! I'm seeing this behavior in version |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
TLDR
When you switch between clusters, k9s "remembers" the aliases/api-resources from your previous cluster. This is bad, since some aliases from a previous cluster can override the proper aliases from your current cluster.
I ran into this with two apiversions of the same custom resource, one older and one newer. However, it happens with any api resources/aliases.
For example, Flux uses the newer
kustomize.toolkit.fluxcd.io/v1/kustomizations
resource with the shortnameks
on one cluster. If you switch to another cluster that uses thekustomize.toolkit.fluxcd.io/v1beta2/kustomizations
resource,:ks
will sometimes try to findkustomize.toolkit.fluxcd.io/v1
and fail with the messageno resource meta defined for "kustomize.toolkit.fluxcd.io/v1/kustomizations"
.To Reproduce
Steps to reproduce the behavior:
Reproduce my specific issue:
:ks
command will only work on one cluster, the specific cluster seems to be inconsistentHistorical Documents
k9s.log
for an example where k9s decided thatks
mapped tokustomize.toolkit.fluxcd.io/v1beta1/kustomizations
and where I was still able to try and findkuma.io/v1alpha1/zoneegresses
from my previous cluster context.Expected behavior
I should only have aliases defined for the context that I'm currently using. I should not "carry over" aliases from other contexts.
Screenshots
Before changing to the second cluster:
After changing to the second cluster
Changing back to the first cluster (note that
ks
maps tov1
and not the correctv1beta2
)Error message from the first cluster
Versions (please complete the following information):
The text was updated successfully, but these errors were encountered: