Bug 1401007 - RHV deployment fails on wait_for_host_up ansible task
Summary: RHV deployment fails on wait_for_host_up ansible task
Keywords:
Status: CLOSED DUPLICATE of bug 1401005
Alias: None
Product: Red Hat Quickstart Cloud Installer
Classification: Red Hat
Component: Installation - RHEV
Version: 1.1
Hardware: All
OS: All
medium
medium
Target Milestone: ---
: ---
Assignee: John Matthews
QA Contact: Sudhir Mallamprabhakara
Dan Macpherson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-02 14:48 UTC by Tasos Papaioannou
Modified: 2017-01-19 15:02 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-02 19:01:35 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Tasos Papaioannou 2016-12-02 14:48:07 UTC
Description of problem:

RHV deployments fail on the wait_for_host_up ansible task:

****
2016-12-01 17:10:05,415 p=32680 u=foreman |  PLAY [self_hosted_first_host] **************************************************
2016-12-01 17:10:05,509 p=32680 u=foreman |  TASK [wait_for_host_up : wait for SSH to respond on host] **********************
2016-12-01 17:10:05,795 p=32680 u=foreman |  ok: [mac525400915636.example.com -> localhost]
2016-12-01 17:10:05,803 p=32680 u=foreman |  TASK [wait_for_host_up : Gather facts] *****************************************
2016-12-01 17:10:06,169 p=32680 u=foreman |  fatal: [mac525400915636.example.com]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh.", "unreachable": true}
2016-12-01 17:10:06,175 p=32680 u=foreman |  PLAY RECAP *********************************************************************
2016-12-01 17:10:06,175 p=32680 u=foreman |  mac525400915636.example.com : ok=1    changed=0    unreachable=1    failed=0 
****

Version-Release number of selected component (if applicable):

QCI-1.1-RHEL-7-20161201.t.0

How reproducible:

100%

Steps to Reproduce:
1.) Start RHV deployment.
2.) See failed deployment.

Actual results:

Failed deployment.

Expected results:

Successful deployment.

Additional info:

Manual ssh into the hypervisor is successful. There is no /root/.ssh/authorized_keys, whereas a successful deployment using the previous compose does have authorized_keys. I'm guessing the recent commits involving ssh key setup are causing ssh-copy-id to fail.

Comment 2 Tasos Papaioannou 2016-12-02 18:02:52 UTC
In /opt/theforeman/tfm/root/usr/share/gems/gems/fusor_server-1.1.13/app/lib/utils/fusor/ssh_key_utils.rb, I changed:

retval = system("sshpass -e ssh-copy-id -i #{get_ssh_private_key_path} -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no #{username}@#{hostname}")

to:

retval = system("sshpass -e ssh-copy-id -i #{get_ssh_private_key_path} -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no #{username}@#{hostname} >/tmp/copy.log 2>&1")

then restarted services and replicated the error. The output file /tmp/copy.log shows the error:

# cat /tmp/copy.log 
Failed to get a pseudo terminal: Permission denied

Comment 3 Jason Montleon 2016-12-02 19:01:35 UTC

*** This bug has been marked as a duplicate of bug 1401005 ***


Note You need to log in before you can comment on or make changes to this bug.