Bug 1565591

Summary: Ansible: Cockpit didn't retrieve the FC lun, just need the user to input the lun id manually
Product: [oVirt] cockpit-ovirt Reporter: Yihui Zhao <yzhao>
Component: Hosted EngineAssignee: Phillip Bailey <phbailey>
Status: CLOSED CURRENTRELEASE QA Contact: Yihui Zhao <yzhao>
Severity: high Docs Contact:
Priority: unspecified    
Version: 0.11.20CC: bugs, cshao, huzhao, jiaczhan, nsednev, phbailey, qiyuan, rbarry, sbonazzo, stirabos, weiwang, yaniwang, ycui, yturgema, yzhao
Target Milestone: ovirt-4.2.3Flags: rule-engine: ovirt-4.2+
rule-engine: exception+
sbonazzo: devel_ack+
yzhao: testing_ack+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: cockpit-ovirt-0.11.23-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-10 06:27:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Integration RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1571467    
Bug Blocks:    
Attachments:
Description Flags
fc
none
pending_fc
none
terminal_display
none
Error on FC discovery
none
fc_getdevices.yml output
none
Successful LUN discovery none

Description Yihui Zhao 2018-04-10 11:18:48 UTC
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:

Comment 1 Yaniv Kaul 2018-04-11 06:37:30 UTC
Are you sure zoning is set correctly?

Comment 3 Yihui Zhao 2018-04-19 06:50:18 UTC
Created attachment 1423930 [details]
pending_fc

Comment 4 Yihui Zhao 2018-04-19 06:50:47 UTC
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

Comment 5 Yihui Zhao 2018-04-19 07:38:42 UTC
Created attachment 1423935 [details]
terminal_display

Comment 6 Ryan Barry 2018-04-20 02:13:04 UTC
This looks like a system/zoning problem. Does this LUN work on the CLI?

Comment 7 Yihui Zhao 2018-04-20 02:39:02 UTC
(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]: 
"""

Comment 8 Phillip Bailey 2018-04-20 12:51:39 UTC
(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?

Comment 9 Simone Tiraboschi 2018-04-20 15:27:18 UTC
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).

Comment 10 Simone Tiraboschi 2018-04-20 15:34:37 UTC
Created attachment 1424588 [details]
Error on FC discovery

Comment 11 Simone Tiraboschi 2018-04-20 15:37:12 UTC
Created attachment 1424592 [details]
fc_getdevices.yml output

Comment 12 Phillip Bailey 2018-04-20 22:31:08 UTC
> 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

Comment 13 Phillip Bailey 2018-04-20 22:31:55 UTC
Created attachment 1424758 [details]
Successful LUN discovery

Comment 14 Yihui Zhao 2018-04-26 02:12:21 UTC
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.

Comment 15 Yihui Zhao 2018-05-03 03:13:00 UTC
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.

Comment 16 Sandro Bonazzola 2018-05-10 06:27:54 UTC
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.