Created attachment 1382347 [details] ssh key regen prompt Description of problem: ========================= When we use colonizer to deploy gluster on a fresh setup, we are asked if we want to regenerate ssh-keys. Once we accept that and proceed, and for some reason the setup failed/aborted, if we rerun colonizer again, it fails due to ssh key errors, even though we again tell it to regenerate ssh keys This means we have to re install all the machines affected again , which is very tedious and time taking This bug impacts the time taken to deploy as factory installing takes time. How reproducible: ==================== hit this a few time , but 100% reproducible Steps to Reproduce: 1. factory setup all machines 2. start colonizer on one machine to install media server 3. now you would be prompted to regenerate ssh keys, accept it (attached screenshot has the prompt) 4. now for some reason make the script fail during further steps or abort it 5. you are told to reboot to restart deployment through colonizer 6. reboot and restart colonizer to deploy media server. 7. accept ssh key regeneration(attached screenshot has the prompt) Actual results: ============ even after regenration of new keys, deployment script fails due to ssh key problems Expected results: ================= once we have accepted for new keys to be regenerated, the script should not fail due to ssh key issues. Additional info: the only way to overcome is to factory setup all affected machines, which is very tedious
I can mitigate this problem by pushing the ssh key regeneration to the phase of the script just before the main playbook runs. At this point, all abort conditions based on user input are past and only failures in the main playbook could cause this problem. This should make it dramatically less likely, but I don't think I can easily solve the problem completely.
Completed as described in comment #2 with upstream merge commit to master d46cf79239daa8ba5c25acea58fb2faf8b8e9b95
verification: I have test this on gluster-colonizer-1.0.3-1.el7rhgs seeing that ssh keys generation is proceeding even if they existed also as based on comment#3, the ssh key generation has been moved to later stage. Hence moving to verified mainly based on what was fixed as part of comment#3
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:0477