02.bootstrap_cluster.sh error about vagrant-caasp HOT 6 CLOSED

It looks like you forgot the "." in front of the ./00.prep_environment.sh.
We have to source this file, rather than run it directly.
Run: ". ./00.prep_environment.sh"
Can you try that and let me know if it works for you?

from vagrant-caasp.

now I get this error:
sles@caasp4-master-1:/vagrant/deploy> . ./00.prep_environment.sh
Agent pid 6264
Identity added: /vagrant/cluster/caasp4-id ([email protected])
sles@caasp4-master-1:/vagrant/deploy> ./01.init_cluster.sh
Initializing cluster...

• skuba cluster init --control-plane caasp4-lb-1 caasp4-cluster
  ** This is a BETA release and NOT intended for production usage. **
  [init] configuration files written to /vagrant/cluster/caasp4-cluster
• set +x
  sles@caasp4-master-1:/vagrant/deploy> ./02.bootstrap_cluster.sh
  Bootstrapping cluster...
• skuba node bootstrap --user sles --sudo --target caasp4-master-1 caasp4-master-1
  ** This is a BETA release and NOT intended for production usage. **
  [bootstrap] updating init configuration with target information
  W0707 12:08:22.074660 6281 ssh.go:306]
  The authenticity of host '127.0.0.1:22' can't be established.
  ECDSA key fingerprint is 0d:2c:e7:0e:8b:b7:80:a8:3e:aa:9a:49:16:6b:57:6a.
  I0707 12:08:22.074768 6281 ssh.go:307] accepting SSH key for "caasp4-master-1:22"
  I0707 12:08:22.074785 6281 ssh.go:308] adding fingerprint for "caasp4-master-1:22" to "known_hosts"
  [bootstrap] writing init configuration for node
  [bootstrap] applying init configuration to node
  F0707 12:12:30.079632 6281 bootstrap.go:48] error bootstraping node: failed to apply state kubeadm.init: Process exited with status 1
• skuba cluster status
  ** This is a BETA release and NOT intended for production usage. **
  E0707 12:12:30.180062 7107 status.go:33] unable to get cluster status: unable to get admin client set: could not load admin kubeconfig file: failed to load admin kubeconfig: open admin.conf: no such file or directory
• set +x
• kubectl get nodes -o wide
  The connection to the server localhost:8080 was refused - did you specify the right host or port?
• set +x

from vagrant-caasp.

I'm not exactly sure what the issue is. We can run increase skuba's verbosity and try to get more information.
Could you change the line in 02.bootstrap_cluster.sh from:
"skuba node bootstrap --user sles --sudo --target caasp4-master-1 caasp4-master-1"
to:
"skuba -v2 node bootstrap --user sles --sudo --target caasp4-master-1 caasp4-master-1"
and then run again?

Will you have time to jump on a quick GTM to go through this? It might be the fastest way to get you up and running.

from vagrant-caasp.

Hi,

I had similar problems, when I tried this on my laptop with openSUSE Leap 15.1 because of firewalld configuration issues.
I first tried to turn of firewalld to enable the guests to reach the kvm-hosts nfs export, but when I did that the guests couldn't reach internet, only the host was accessible.
That resulted in error when skuba tried to pull images from the repository.

The resolution to my problem was to enable firewalld and create a zone that accepted NFS.
see more here #3

from vagrant-caasp.

I had similar problems while running the skuba node bootstrap --user sles --sudo --target caasp4-master-1 caasp4-master-1 portion of 02.bootstrap_cluster.sh.

Steven helped me out and by running skuba -v2 node bootstrap --user sles --sudo --target caasp4-master-1 caasp4-master-1 we found this error: [ERROR ImagePull]: failed to pull image registry.suse.com/caasp/v4/hyperkube:v1.14.1: output: time="2019-07-08T11:20:16-05:00" level=fatal msg="pulling image failed: rpc error: code = Unknown desc = pinging docker registry returned: Get https://registry.suse.com/v2/: dial tcp: lookup registry.suse.com on 192.168.121.1:53: read udp 192.168.121.120:55033->192.168.121.1:53: i/o timeout"

It turns out that my KVM host's primary DNS server was one that no longer existed. The secondary DNS server is 8.8.8.8 so most everything else on the server works normally, just that DNS resolution takes five seconds longer. That extra five seconds was enough to cause the image pulls to fail. Commenting out the missing DNS server in /etc/resolv.conf allowed the skuba bootstrap command to complete successfully.

One potential pre-flight test could be to run time getent hosts registry.suse.com to ensure resolution completes in less than one or two seconds.

from vagrant-caasp.

We found the root of the issue:
when for some reason you need to recreate the vagrant-libvirt network, you shoud delete <uuid>4956b3c4-1fa2-4912-960f-ac197ed6b905</uuid> in vagrant-libvirt.xml, otherwise the dns allocation will be wrong

from vagrant-caasp.