Created attachment 1419839 [details] fc Description of problem: Cockpit didn't retrieve the FC lun, just need the user to input the lun id manually. Version-Release number of selected component (if applicable): rhvh-4.2.2.1-0.20180406.0+1 cockpit-ovirt-dashboard-0.11.20-1.el7ev.noarch ovirt-hosted-engine-ha-2.2.9-1.el7ev.noarch ovirt-hosted-engine-setup-2.2.15-1.el7ev.noarch rhvm-appliance-4.2-20180404.0.el7.noarch How reproducible: 100% Steps to Reproduce: 1. Deploy HE with fc storage via cockpit Actual results: The same as the description. Expected results: Cockpit can retrieve the fc lun while deploying HE Additional info:
Are you sure zoning is set correctly?
Created attachment 1423930 [details] pending_fc
Tested with cockpit-ovirt-dashboard-0.11.22-1.el7ev.noarch from the cockpit, when selecting the FC storage, it will retrieve the luns. But it didn't retrieve the correct luns, and pending on the 'Retrieving LUNs' progress. Also, it didn't cancel this operation 'retrieve luns' from cockpit. See attachment: https://bugzilla.redhat.com/attachment.cgi?id=1423930
Created attachment 1423935 [details] terminal_display
This looks like a system/zoning problem. Does this LUN work on the CLI?
(In reply to Ryan Barry from comment #6) > This looks like a system/zoning problem. Does this LUN work on the CLI? From the CLI, it works well, retrieve luns successfully. """ [ INFO ] TASK [Get Fibre Channel LUNs] [ INFO ] ok: [localhost] The following luns have been found on the requested target: [1] 36005076300810b3e0000000000000025 200GiB IBM 2145 status: free, paths: 2 active [2] 36005076300810b3e0000000000000026 100GiB IBM 2145 status: free, paths: 2 active [3] 36005076300810b3e0000000000000027 100GiB IBM 2145 status: free, paths: 2 active [4] 3600508b1001c94646ba0271afaaa249e 558GiB HP LOGICAL VOLUME status: free, paths: 1 active Please select the destination LUN (1, 2, 3, 4) [1]: """
(In reply to Yihui Zhao from comment #4) > from the cockpit, when selecting the FC storage, it will retrieve the luns. > But it didn't retrieve the correct luns, and pending on the 'Retrieving > LUNs' progress. Could you please clarify this for me? Are you saying that it retrieved LUNs, but they weren't the correct LUNs? Or that it didn't retrieve the LUNs at all and the UI stays hung on the spinner?
OK, reproduced, attaching a screenshot. In broweser console I see: Get fiber channel LUNs started. app.js:25 Get fiber channel LUNs completed successfully. app.js:25 Error: TypeError: Cannot read property 'imgSizeGB' of undefined app.js:25 Uncaught (in promise) TypeError: Cannot read property 'imgSizeGB' of undefined at i (app.js:25) at d._constructComponentWithoutOwner (app.js:25) at d._constructComponent (app.js:25) at d.mountComponent (app.js:25) at Object.mountComponent (app.js:11) at d.performInitialMount (app.js:25) at d.mountComponent (app.js:25) at Object.mountComponent (app.js:11) at b.mountChildren (app.js:25) at b._createInitialChildren (app.js:25) I can successfully directly execute the FC discovery playbook on the same env (attaching a log).
Created attachment 1424588 [details] Error on FC discovery
Created attachment 1424592 [details] fc_getdevices.yml output
> Could you please clarify this for me? Are you saying that it retrieved LUNs, > but they weren't the correct LUNs? Or that it didn't retrieve the LUNs at > all and the UI stays hung on the spinner? Disregard
Created attachment 1424758 [details] Successful LUN discovery
Tested with cockpit-ovirt-0.11.23-1, now cockpit can retrieve fc lun, but due to other block bug: https://bugzilla.redhat.com/show_bug.cgi?id=1571467, deployment fails on fc storage. I will test again if bug 1571467 fixed.
Works for me with these component: ovirt-hosted-engine-ha-2.2.11-1.el7ev.noarch ovirt-hosted-engine-setup-2.2.20-1.el7ev.noarch rhvm-appliance-4.2-20180427.0.el7.noarch cockpit-dashboard-165-3.el7.x86_64 cockpit-bridge-165-3.el7.x86_64 cockpit-165-3.el7.x86_64 cockpit-storaged-165-3.el7.noarch cockpit-ws-165-3.el7.x86_64 cockpit-ovirt-dashboard-0.11.23-1.el7ev.noarch cockpit-system-165-3.el7.noarch rhvh-4.2.3.0-0.20180430.0+1 ansible-2.5.2-1.el7ae.noarch Moving to verify.
This bugzilla is included in oVirt 4.2.3 release, published on May 4th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.3 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.