Description of problem: When the hostnames for all hosts were set to resolve to a floating ip on OpenStack, atomic-openshift-installer would pause to give a warnning and let user to press CTRL-C to continue. But it works well to press ENTER instead of CTRL-C. It could set "openshift_override_hostname_check=true" to skip the warnning in openshift-ansible, but failed to do that in atomic-openshift-installer. Also it seems useless to give the warnning to users. So it's better and resonable to remove the interaction. Version-Release number of selected component (if applicable): atomic-openshift-utils-3.0.40-1.git.22.da21865.el7aos.noarch How reproducible: Steps to Reproduce: 1.Prepare two hosts which hostnames were resolving to a floating ip. 2.Start a basic installation by atomic-openshift-installer. 3. Actual results: TASK: [Warn user about bad openshift_hostname values] ************************* [10.66.79.147, 10.66.79.158] The hostname "openshift-147.lab.eng.nay.redhat.com" for "openshift-147.lab.eng.nay.redhat.com" doesn't resolve to an ip address owned by this host. Please set openshift_hostname variable to a hostname that when resolved on the host in question resolves to an IP address matching an interface on this host. This host will fail liveness checks for pods utilizing hostPorts, press CTRL-C to continue.: Failed to continue when press CTRL-C as above warnning. But it works well to press ENTER instead of CTRL-C. Expected results: Modify CTRL-C as ENTER. It's better the installer gives the warnning, and continues the installation without the interaction. Additional info:
Test with openshift-ansible-3.0.41-1.git.0.2446a82.el7aos.noarch The warnning message had been changed correctly. But when pressing CTRL-C ,the terminal was in trouble, had to reopen a terminal. <--snip--> The hostname "ghuang-verfify-bug.novalocal" for "openshift-130.lab.eng.nay.redhat.com" doesn't resolve to an ip address owned by this host. Please set openshift_hostname variable to a hostname that when resolved on the host in question resolves to an IP address matching an interface on this host. This host will fail liveness checks for pods utilizing hostPorts, press ENTER to continue or CTRL-C to abort.: ^C Action? (a)bort/(c)ontinue: Aborted! [ghuang ~]$ fatal: [10.66.79.130] => Traceback (most recent call last): <--snip-->
Is this simply your terminal drawing things incorrectly? Meaning, if you press enter are you given a new prompt with an empty line? Here's what the output looked like for me: TASK: [Warn user about bad openshift_hostname values] ************************* [ip-172-18-8-33.ec2.internal] The hostname "ip-172-18-8-33.ec2.internal" for "ip-172-18-8-33.ec2.internal" doesn't resolve to an ip address owned by this host. Please set openshift_hostname variable to a hostname that when resolved on the host in question resolves to an IP address matching an interface on this host. This host will fail liveness checks for pods utilizing hostPorts, press ENTER to continue or CTRL-C to abort.: ^C Action? (a)bort/(c)ontinue: Action? (a)bort/(c)ontinue: Action? (a)bort/(c)ontinue: fatal: [ip-172-18-8-33.ec2.internal] => user requested abort! FATAL: all hosts have already failed -- aborting PLAY RECAP ******************************************************************** to retry, use: --limit @/root/config.retry ip-172-18-8-33.ec2.internal : ok=8 changed=2 unreachable=0 failed=1 localhost : ok=10 changed=0 unreachable=0 failed=0 I hit CTRL-C a few times to see if I could get the terminal to mess up. I don't think there is a bug here with ansible or the playbooks. It could very well be the case that the terminal can display garbage under certain situations. Please past the entire error you see if this happens again.
Thanks for the logs! It turns out this only happens when running ansible through atomic-openshift-installer. That's where the "Aborted!" message is coming from. I suspect the most correct thing to do would be to trap the signal and pass it to the ansible subprocess. If we can't do that easily we should at least find a way to prevent it from messing up the terminal. On a side note, typing 'reset' in bash will clean things up so you don't have to open a new terminal. While this is certainly annoying I don't think we need to block the 3.1.1.6 update release on this. I'm going to remove this bug from the advisory.
I am unable to reproduce any kind of error conditions. Testing with: > $ cat /etc/fedora-release > Fedora release 23 (Twenty Three) * openshift-ansible-roles-3.3.12-1.git.3.618e64f.fc23.noarch * openshift-ansible-playbooks-3.3.12-1.git.3.618e64f.fc23.noarch * openshift-ansible-lookup-plugins-3.3.12-1.git.3.618e64f.fc23.noarch * openshift-ansible-filter-plugins-3.3.12-1.git.3.618e64f.fc23.noarch * openshift-ansible-docs-3.3.12-1.git.3.618e64f.fc23.noarch * openshift-ansible-3.3.12-1.git.3.618e64f.fc23.noarch * atomic-openshift-utils-3.3.12-1.git.3.618e64f.fc23.noarch Forced the "Warn user about bad openshift_hostname values" task to appear by removing the "when" condition. First test, pressing ctrl+c and then 'c' (to continue) "host will fail liveness checks for pods utilizing hostPorts, press ENTER to continue or CTRL-C to abort.:" > PRESSED CTRL-C HERE, then this message appeared: Press 'C' to continue the play or 'A' to abort ok: [54.237.208.132] Then I killed it manually with another ctrl-c. Second test, pressing ENTER "host will fail liveness checks for pods utilizing hostPorts, press ENTER to continue or CTRL-C to abort.:" > PRESSED ENTER HERE TO CONTINUE then got this message ok: [54.237.208.132] Gan, is there a specific issue you're still having?
Tim, I can't reproduce it with latest 3.3/3.2 atomic-openshift-utils packages as well. # rpm -qa |grep ansible openshift-ansible-3.3.12-1.git.0.b26c8c2.el7.noarch openshift-ansible-roles-3.3.12-1.git.0.b26c8c2.el7.noarch ansible-2.2.0-0.5.prerelease.el7.noarch openshift-ansible-docs-3.3.12-1.git.0.b26c8c2.el7.noarch openshift-ansible-filter-plugins-3.3.12-1.git.0.b26c8c2.el7.noarch openshift-ansible-playbooks-3.3.12-1.git.0.b26c8c2.el7.noarch openshift-ansible-lookup-plugins-3.3.12-1.git.0.b26c8c2.el7.noarch But I'm able to reproduce it with following packages: # rpm -qa |grep ansible ansible-1.9.4-1.el7aos.noarch openshift-ansible-roles-3.0.47-1.git.0.4498ce3.el7aos.noarch openshift-ansible-3.0.47-1.git.0.4498ce3.el7aos.noarch openshift-ansible-filter-plugins-3.0.47-1.git.0.4498ce3.el7aos.noarch openshift-ansible-playbooks-3.0.47-1.git.0.4498ce3.el7aos.noarch openshift-ansible-lookup-plugins-3.0.47-1.git.0.4498ce3.el7aos.noarch So it's definitely a bug for 3.1.