tinkerbell/playground

Pulling in helm fails

Closed this issue · 7 comments

stappersg commented

Expected Behaviour

Smooth vagrant up for provisioner.

Current Behaviour

What I got:

   ...
    provisioner: node/k3d-k3s-default-server-0 condition met
    provisioner: + install_helm
    provisioner: + helm_ver=v3.9.4
    provisioner: + curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
    provisioner: + chmod 700 get_helm.sh
    provisioner: + ./get_helm.sh --version v3.9.4
    provisioner: Downloading https://get.helm.sh/helm-v3.9.4-linux-amd64.tar.gz
    provisioner: Verifying checksum... Done.
    provisioner: Preparing to install helm into /usr/local/bin
    provisioner: helm installed into /usr/local/bin/helm
    provisioner: + helm_customize_values 192.168.56.5 0.1.2
    provisioner: + local loadbalancer_ip=192.168.56.5
    provisioner: + local helm_chart_version=0.1.2
    provisioner: + helm inspect values oci://ghcr.io/tinkerbell/charts/stack --version 0.1.2
    provisioner: + sed -i s/192.168.2.111/192.168.56.5/g /tmp/stack-values.yaml
    provisioner: + helm_install_tink_stack tink-system 0.1.2 eth1
    provisioner: + local namespace=tink-system
    provisioner: + local version=0.1.2
    provisioner: + local interface=eth1
    provisioner: ++ kubectl get nodes -o 'jsonpath={.items[*].spec.podCIDR}'
    provisioner: ++ tr ' ' ,
    provisioner: + trusted_proxies=10.42.0.0/24
    provisioner: + helm install stack-release oci://ghcr.io/tinkerbell/charts/stack --version 0.1.2
       --create-namespace  --namespace tink-system --wait
       --set boots.boots.trustedProxies=10.42.0.0/24
       --set hegel.hegel.trustedProxies=10.42.0.0/24 --set kubevip.interface=eth1
       --values /tmp/stack-values.yaml
    provisioner: Error: INSTALLATION FAILED: timed out waiting for the condition
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
stappers@yanur:~/src/tinkerbell/sandbox/deploy/infrastructure/vagrant
$

Possible Solution

If you're suggesting a change/improvement, tell us how it should work.

An outcome as documented on https://github.com/tinkerbell/sandbox/blob/main/docs/quickstarts/VAGRANTLVIRT.md

Maybe previnting the installation of helm???

Steps to Reproduce

Following https://github.com/tinkerbell/sandbox/blob/main/docs/quickstarts/VAGRANTLVIRT.md
Additional information below.

Context

What are you trying to accomplish?

First encounter with Tinkerbell.

Environment

  • Debian testing
  • Using Vagrant & Libvirt
stappersg commented

FWIW: With vagrant ssh provisioner I get this on the inside:

vagrant@ubuntu2204:~$ helm install stack-release oci://ghcr.io/tinkerbell/charts/stack
   --version 0.1.2 --create-namespace --namespace tink-system --wait
   --set boots.boots.trustedProxies=10.42.0.0/24
   --set hegel.hegel.trustedProxies=10.42.0.0/24
   --set kubevip.interface=eth1 --values /tmp/stack-values.yaml
Error: INSTALLATION FAILED: Kubernetes cluster unreachable:
    Get "http://localhost:8080/version": dial tcp 127.0.0.1:8080: connect: connection refused
vagrant@ubuntu2204:~$ sudo ss -ltp
State    Recv-Q   Send-Q      Local Address:Port              Peer Address:Port   Process                                      
LISTEN   0        4096            127.0.0.1:10248                  0.0.0.0:*       users:(("k3s",pid=3473,fd=216))             
LISTEN   0        4096            127.0.0.1:10249                  0.0.0.0:*       users:(("k3s",pid=3473,fd=251))             
LISTEN   0        4096            127.0.0.1:sge-qmaster            0.0.0.0:*       users:(("k3s",pid=3473,fd=17))              
LISTEN   0        4096            127.0.0.1:10256                  0.0.0.0:*       users:(("k3s",pid=3473,fd=248))             
LISTEN   0        4096            127.0.0.1:10257                  0.0.0.0:*       users:(("k3s",pid=3473,fd=227))             
LISTEN   0        4096            127.0.0.1:10258                  0.0.0.0:*       users:(("k3s",pid=3473,fd=242))             
LISTEN   0        4096            127.0.0.1:10259                  0.0.0.0:*       users:(("k3s",pid=3473,fd=250))             
LISTEN   0        4096        127.0.0.53%lo:domain                 0.0.0.0:*       users:(("systemd-resolve",pid=502,fd=14))   
LISTEN   0        128               0.0.0.0:ssh                    0.0.0.0:*       users:(("sshd",pid=1182,fd=3))              
LISTEN   0        4096            127.0.0.1:10010                  0.0.0.0:*       users:(("containerd",pid=3533,fd=16))       
LISTEN   0        4096                    *:10250                        *:*       users:(("k3s",pid=3473,fd=222))             
LISTEN   0        4096                    *:6443                         *:*       users:(("k3s",pid=3473,fd=14))              
LISTEN   0        4096                    *:http                         *:*       users:(("boots",pid=5642,fd=7))             
LISTEN   0        128                  [::]:ssh                       [::]:*       users:(("sshd",pid=1182,fd=4))              
LISTEN   0        4096                    *:2112                         *:*       users:(("kube-vip",pid=5439,fd=7))          
vagrant@ubuntu2204:~$

I think that culprit is not installing helm.

jacobweinstock commented

Hey @stappersg , thanks for trying out the sandbox and reporting this issue. I have tried to reproduce this but I haven't been able to, unfortunately. Would you mind posting the entire output from the vagrant up command? The initial error you posted appears to be a timeout from the helm install command. the second error you posted looks like helm was unable to communicate with the local K3s Kubernetes clusters. This makes me think that possibly there was something wrong with the k3d create cluster command.

stappersg commented

Summary: Sorry

I, new to vagrant, was unable reproduce what I had last month.

I did found traces of my previous attempt, so I'm on the same computer as end of November.

Now doing vagrant up gets me

No usable default provider could be found for your system.

Vagrant relies on interactions with 3rd party systems, known as
"providers", to provide Vagrant with resources to run development
environments.

Visiting https://github.com/tinkerbell/sandbox/blob/main/docs/quickstarts/VAGRANTLVIRT.md
once again, I did see

cd deploy/infrastructure/vagrant

However, there is no such directory.

stappers@myhost:~/src/tinkerbell/sandbox
$ cd deploy/infrastructure/vagrant
bash: cd: deploy/infrastructure/vagrant: No such file or directory
stappers@myhost:~/src/tinkerbell/sandbox
$ ls deploy/
compose  terraform  vagrant
stappers@myhost:~/src/tinkerbell/sandbox
$ ls deploy/vagrant/
Vagrantfile  setup.sh  tink
stappers@myhost:~/src/tinkerbell/sandbox
$
stappersg commented

(several minutes later)

  • Getting vagrant working failed also (in the time had to spend)
  • For me is this not a tinkerbell issue anymore
  • I leave the issue open (a.k.a. abanden it)
  • I hope that cd deploy/infrastructure/vagrant versus cd deploy/vagrant gets fixed.
jacobweinstock commented

Hey @stappersg, thanks for the update. Do you know which commit for sandbox you have? The deploy/vagrant directory structure is not what the latest release and top of tree has.

stappersg commented

Oops, I was in wrong git branch.

Back in branch main I can do cd deploy/infrastructure/vagrant succesfull. ( vagrant up still fails. )

The I have tried to reproduce this but I haven't been able to, unfortunately. from @jacobweinstock plus no vagrant from me, made me closing this issue.

jacobweinstock commented

Hey @stappersg, please feel free to reopen this if/when you get vagrant installed and want to continue troubleshooting together.