-
Notifications
You must be signed in to change notification settings - Fork 23
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
tanzu-cli 1.4.1 on Linux context create hangs on kubernetes-release #825
Comments
I attempted to add 8GB of memory and rerun. It's almost as if there is a memory leak somewhere. I am watching "free -h" during this step and in a matter of 20 seconds it eats up all available memory when hitting this step. I have tried removing all tanzu related folders, and the effect is the same
|
To add to my confusion, I tried upgrading Alma and Tanzu-CLI to latest 1.5 from the new repo. Using the same context command I now get a hard error:
Same result in interactive:
Update Edit: I have now tried this on a fresh WSL Ubuntu instance with latest kubectl and both Tanzu 1.5 and 1.4.1. The outputs remain the same, 1.4.1 hangs and chews up memory. 1.5 errors out. I am very confused :( |
Furthermore, on windows if I upgrade tanzu-cli to v1.5.1 I get this when creating the same exact context (which works on windows v1.4.1):
|
I have tried following the air-gapped instructions, and the result is the same. |
More anallysis vcenter version including build: VMware® vSphere® vSphere Client version 8.0.2.00000 Build 22617221 ### On Windows Tanzu-CLI v1.4.1 - MOSTLY success
### On Windows Tanzu-CLIv1.5.1 - FAIL
### On Linux Tanzu-CLI v1.4.1 - FAIL
### On Linux Tanzu-CLI v1.4.1 without using group install first - FAIL
I click on the link at this point
### On Linux Tanzu-CLI v1.5.1 - FAIL:
My only reason for needing to login using tanzu as opposed to normal kubectl (which works):
... is because I'm using an external IdP workflow (which is clearly OK if 1.4.1 on windows works). To my knowledge there is no other way to do auth to an external IdP without the tanzu client. |
Its worth nothing that if I save config-ng.yaml from a tanzu context create using v1.4.1 and then copy it back after installing tanzu-cli 1.5.1, I can retrieve cluster objects just fine. |
I also get error while validating the Context object: context name cannot be empty With the latest changes and tanzu cli 1.5.1 |
The only work around that i have for this is the following to get a valid oidc auth working with tanzu-cli # This will fail out and create a new context in your kubeconfig
tanzu context create context-name --endpoint https://some.fqdn.com
# Rename the newly created context name to something useful
kubectl config rename-context tanzu-cli-{guid-id}@{guid-id} new-context-name
# Add it to tanzu context create
tanzu context create context-name --kubeconfig ~/.kube/config --kubecontext new-context-name |
Hi @dsputnikk I see the issue with the code, our org has a active support ticket opened for this internally , ill work on doing a MR and explanation. |
Bug description
I am essentially here: https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-with-tanzu-tkg/GUID-E5A804FA-BB03-436F-BF01-14CBF13DBB9D.html . Attemping to create a context against my Tanzu environment.
This works on Windows with tanzu-cli 1.4.1 down to generating me my kubeconfig. The same exact process, same endpoints, hangs on linux.
There is a load of CPU activity from the kswap0 process during this hang. My only way to exit is to eventually ctrl c out of it as the system becomes quite unresponsive.
Expected behavior
Plugins are installed and drops back out to shell, ready to move on to listing/connecting to a tanzu namespace.
Steps to reproduce the bug / Relevant debug output
Output of
tanzu version
on both OS'es
Environment where the bug was observed (cloud, OS, etc)
Win11 or Alma 9.1
The text was updated successfully, but these errors were encountered: