You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From my understanding, kuberlr queries the remote cluster for its version every time kubectl is invoked. This is way too slow to be practical -- it takes several seconds to get anything from, for example, EKS. Even working with a local cluster like Rancher Desktop has a noticeable slowdown.
It would be nice if kuberlr would automatically cache the version for each cluster it is used with, and refer to it when deciding which version of kubectl to use. If more than a day (or some other configurable amount of time) has passed between the last time a version was cached, it would only then make the extra query for the version.
The text was updated successfully, but these errors were encountered:
There are some situations where kuberlr is used (e.g., Rancher Desktop) where the version can change more often. Such as when you're testing workloads under Kubernetes version upgrades. When caching is used there should be a way to handle this well.
Also adding "source <(kubectl completion zsh)" to .zshrc slows down opening a new shell if there is no access to the current context. For example if the API is closed by VPN and VPN is switched off.
From my understanding, kuberlr queries the remote cluster for its version every time kubectl is invoked. This is way too slow to be practical -- it takes several seconds to get anything from, for example, EKS. Even working with a local cluster like Rancher Desktop has a noticeable slowdown.
It would be nice if kuberlr would automatically cache the version for each cluster it is used with, and refer to it when deciding which version of kubectl to use. If more than a day (or some other configurable amount of time) has passed between the last time a version was cached, it would only then make the extra query for the version.
The text was updated successfully, but these errors were encountered: