"swapoff" still need to be done manually

[Hui-Zhi]

I found that "swapoff" still need to be done manually if you want to init master or join node, and there's no log can give me a hint this need to be done manually.

You can see log below:

hui-zhi@linux-2kew:~/caasp> skuba node join --role worker --user hui-zhi --sudo --target 10.67.20.97 node1
W0926 18:05:15.989078   14507 ssh.go:306] 
The authenticity of host '10.67.20.97:22' can't be established.
ECDSA key fingerprint is 30:8a:10:f1:4f:c2:75:1e:bb:f4:65:fb:b0:2f:f5:bf.
I0926 18:05:15.989141   14507 ssh.go:307] accepting SSH key for "10.67.20.97:22"
I0926 18:05:15.989149   14507 ssh.go:308] adding fingerprint for "10.67.20.97:22" to "known_hosts"
[join] applying states to new node
[join] failed to apply join to node failed to apply state kubeadm.join: Process exited with status 1
F0926 18:08:03.703525   14507 join.go:51] error joining node node1: failed to apply state kubeadm.join: Process exited with status 1
hui-zhi@linux-2kew:~/caasp> sudo swapoff -a
hui-zhi@linux-2kew:~/caasp> skuba node join --role worker --user hui-zhi --sudo --target 10.67.20.97 node1
[join] applying states to new node
[join] node successfully joined the cluster
hui-zhi@linux-2kew:~/caasp> 

[kravciak]

There is information about swap removal in our documentation

There is also bug#1151689 about default verbosity level.

Can you see error about swap problem in your output when you run skuba with -v 5 argument?

[Hui-Zhi]

IMHO, I don't think we should assume every CaaSP customer start with SLE15-SP1 installation, they may have exist SLE15-SP1 with swap enabled. we should expose the useful kubeadm log and only hide what we can handle automatically. The current log doesn't help.

I have not tried with -v 5 argument, but I think we need to show what exactly failed and what we recommend customer to do.

[alefnode]

You can see it on log if you uses "-v 3"

In the documentation you could put a warning indicating that is needed to disable "swap" in /etc/fstab

[r0ckarong]

IMHO, I don't think we should assume every CaaSP customer start with SLE15-SP1 installation, they may have exist SLE15-SP1 with swap enabled. we should expose the useful kubeadm log and only hide what we can handle automatically. The current log doesn't help.

I have not tried with -v 5 argument, but I think we need to show what exactly failed and what we recommend customer to do.

We specifically had this reported by someone who installed on existing SLE

https://github.com/SUSE/doc-caasp/issues/517

Is manual disabling of SWAP still necessary for other installation types?

[Hui-Zhi]

IMHO, I don't think we should assume every CaaSP customer start with SLE15-SP1 installation, they may have exist SLE15-SP1 with swap enabled. we should expose the useful kubeadm log and only hide what we can handle automatically. The current log doesn't help. I have not tried with -v 5 argument, but I think we need to show what exactly failed and what we recommend customer to do.

We specifically had this reported by someone who installed on existing SLE

SUSE/doc-caasp#517

Is manual disabling of SWAP still necessary for other installation types?

On bare metal, yes, but not sure about others. I think we should expose the "swap off" to customers if it caused by it, even without "-v 5" argument.