Created attachment 1400736 [details] issue1 Description of problem: Don't start HE deployment after upgrading to cockpit-ovirt-dashboard-0.11.12. When starting the deployment, but cockpit keeps "loading" status. Version-Release number of selected component (if applicable): cockpit-system-160-2.el7.noarch cockpit-ws-160-2.el7.x86_64 cockpit-storaged-160-2.el7.noarch cockpit-dashboard-160-2.el7.x86_64 ovirt-hosted-engine-setup-2.2.10-1.el7ev.noarch ovirt-hosted-engine-ha-2.2.5-1.el7ev.noarch cockpit-ovirt-dashboard-0.11.12-0.1.el7ev.noarch (upgrade from cockpit-ovirt-dashboard-0.11.11 to cockpit-ovirt-dashboard-0.11.12) cockpit-bridge-160-2.el7.x86_64 cockpit-160-2.el7.x86_64 rhvh-4.2.1.3-0.20180218.0+1 rhvm-appliance-4.2-20180202.0.el7.noarch How reproducible: 100% Steps to Reproduce: 1. Install RHVH7.5 (rhvh-4.2.1.3-0.20180218.0+1) 2. Deploy HE via cockpit based otopi Actual results: Don't start HE deployment after upgrading to cockpit-ovirt-dashboard-0.11.12. Expected results: Deploy HE successfully Additional info:
Tested on RHEL7.5 also met this issue. Version: Red Hat Enterprise Linux Server 7.5 Beta (Maipo) ovirt-hosted-engine-ha-2.2.6-1.el7ev.noarch cockpit-ovirt-dashboard-0.11.12-0.1.el7ev.noarch ovirt-hosted-engine-setup-2.2.11-1.el7ev.noarch cockpit-storaged-158-1.el7.noarch cockpit-bridge-157-1.el7.x86_64 cockpit-157-1.el7.x86_64 cockpit-dashboard-158-1.el7.x86_64 cockpit-ws-157-1.el7.x86_64 cockpit-system-157-1.el7.noarch
Created attachment 1401567 [details] ansible_issue.png
Ansible deployment also met this issue. See the attachment: https://bugzilla.redhat.com/attachment.cgi?id=1401567
Please verify these on the latest 7.4 build with cockpit-ovirt. There is nothing in 7.5 they depend on
Tested on the RHEL 7.4 build with cockpit-ovirt also met this issue.
I'm starting to believe this is hardware specific. I'm not able to reproduce on any of my systems. The originally reported bug (on RHEL-H) hung on `ansible all -i 'localhost,' -m setup`, which cockpit-ovirt uses for fact gathering. I wonder if we've hit an ansible bug. Is the system for 7.4 the same as 7.5? Does this succeed on other systems?
Sorry, that should be `ansible all -i 'localhost,' -m setup` The all is important
(In reply to Ryan Barry from comment #10) > Sorry, that should be `ansible all -i 'localhost,' -m setup` > > The all is important Yes, it hit an ansible bug. [root@dell-per515-02 ~]# ansible all -i 'localhost,' -m setup The authenticity of host 'localhost (::1)' can't be established. ECDSA key fingerprint is SHA256:IzHm5AByG9LP6OWPDSC7RjWh4lNkutle4WfkN4N0JMc. ECDSA key fingerprint is MD5:18:28:63:86:14:b5:cd:b9:78:c2:60:04:af:72:f9:30. Are you sure you want to continue connecting (yes/no)? yes localhost | UNREACHABLE! => { "changed": false, "msg": "Failed to connect to the host via ssh: Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.\r\nPermission denied (publickey,gssapi-keyex,gssapi-with-mic,password).\r\n", "unreachable": true }
This is actually normal. Ansible expects passwordless auth (ssh-keygen && ssh-copy-id) or to use an option (maybe --ask-pass, but ansible --help will show you) The bug I saw was that ansible never returned and hung. What about comment#8? Same system on 7.4 and 7.5?
(In reply to Ryan Barry from comment #12) > This is actually normal. Ansible expects passwordless auth (ssh-keygen && > ssh-copy-id) or to use an option (maybe --ask-pass, but ansible --help will > show you) > > The bug I saw was that ansible never returned and hung. > > What about comment#8? Same system on 7.4 and 7.5? Yes, The same on 7.4 and 7.5.
Created attachment 1402866 [details] click_no_response.png
Update: Tested cockpit-ovirt-0.11.13-0.1 on RHEL 7.4 See attachment 1402866 [details](https://bugzilla.redhat.com/attachment.cgi?id=1402866) When click "next" button, then no response and cannot reach the next step.
Tested cockpit-ovirt-0.11.14-0.1 on RHEL7.4 without this issue. Test version: Red Hat Enterprise Linux Server 7.4 Beta (Maipo) ovirt-hosted-engine-ha-2.2.6-1.el7ev.noarch cockpit-ovirt-dashboard-0.11.14-0.1.el7ev.noarch ovirt-hosted-engine-setup-2.2.11-1.el7ev.noarch cockpit-storaged-158-1.el7.noarch cockpit-bridge-157-1.el7.x86_64 cockpit-157-1.el7.x86_64 cockpit-dashboard-158-1.el7.x86_64 cockpit-ws-157-1.el7.x86_64 cockpit-system-157-1.el7.noarch rhvm-appliance-4.2-20180202.0.el7.noarch So, I will change the bug's status to verified when it become ON_QA.
Due to Comment 28, and not fix on 4.2.2, so change bug's status to assigned to track.
Please see comment#20, and the title of this bug. This bug is _not_ for anything related to ansible. When it was filed, I thought it was an ansible issue, but is otopi only. Since otopi works with 0.11.14 per comment#20, we should verify this bug
(In reply to Ryan Barry from comment #30) > Please see comment#20, and the title of this bug. > > This bug is _not_ for anything related to ansible. When it was filed, I > thought it was an ansible issue, but is otopi only. > > Since otopi works with 0.11.14 per comment#20, we should verify this bug Got it, I will track ansible issue using the bug:https://bugzilla.redhat.com/show_bug.cgi?id=1539560
From the Comment 20 and Comment 30, deploy HE with otopi flow successfully. Using bug :https://bugzilla.redhat.com/show_bug.cgi?id=1539560 to track ansible issue. Change the bug's status to verified.
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.