Bug 1539598
Summary: | Retrieval of iSCSI targets failed while deploying HE via cockpit based otopi deployment. | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [oVirt] cockpit-ovirt | Reporter: | Yihui Zhao <yzhao> | ||||||||||||||||||
Component: | Hosted Engine | Assignee: | Phillip Bailey <phbailey> | ||||||||||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Yihui Zhao <yzhao> | ||||||||||||||||||
Severity: | high | Docs Contact: | |||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||
Version: | --- | CC: | bugs, cshao, dfediuck, huzhao, phbailey, qiyuan, rbarry, sbonazzo, stirabos, weiwang, yaniwang, ycui, ykaul, ylavi, yzhao | ||||||||||||||||||
Target Milestone: | ovirt-4.2.2 | Keywords: | Reopened | ||||||||||||||||||
Target Release: | --- | Flags: | rule-engine:
ovirt-4.2+
ylavi: blocker+ cshao: testing_ack+ |
||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||
Whiteboard: | |||||||||||||||||||||
Fixed In Version: | cockpit-ovirt-0.11.8-0.1 | Doc Type: | Known Issue | ||||||||||||||||||
Doc Text: |
Previously, when deploying the hosted engine using cockpit, if the LUN number was entered in the "Destination LUN" field for an iSCSI IQN, the deployment failed, because the expected value was the LUN UID. In the current release, if the "Destination LUN" field is left empty, deployment over iSCSI succeeds.
|
Story Points: | --- | ||||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||||
Last Closed: | 2018-03-29 11:03:17 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: | |||||||||||||||||||||
Bug Blocks: | 1529226 | ||||||||||||||||||||
Attachments: |
|
Description
Yihui Zhao
2018-01-29 09:50:18 UTC
Created attachment 1387675 [details]
cockpit_failed.png
*** Bug 1541029 has been marked as a duplicate of this bug. *** Per Simone, this went into 4.2.1 Still failing in cockpit-ovirt-0.11.9-0.1 2018-02-02 13:22:25,653+0100 DEBUG otopi.context context.dumpEnvironment:833 ENV OVEHOSTED_STORAGE/iSCSIPortalIPAddress=str:'192.168.1.125' 2018-02-02 13:22:25,653+0100 DEBUG otopi.context context.dumpEnvironment:833 ENV OVEHOSTED_STORAGE/iSCSIPortalPassword=str:'' 2018-02-02 13:22:25,653+0100 DEBUG otopi.context context.dumpEnvironment:833 ENV OVEHOSTED_STORAGE/iSCSIPortalPort=str:'3260' 2018-02-02 13:22:25,653+0100 DEBUG otopi.context context.dumpEnvironment:833 ENV OVEHOSTED_STORAGE/iSCSIPortalUser=str:'' 2018-02-02 13:22:25,653+0100 DEBUG otopi.context context.dumpEnvironment:833 ENV OVEHOSTED_STORAGE/iSCSITargetName=str:'' 2018-02-02 13:27:00,111+0100 DEBUG otopi.plugins.gr_he_setup.storage.blockd blockd._customization:696 target: , tpgt: 1 2018-02-02 13:27:00,111+0100 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-setup/storage/blockd.py", line 699, in _customization ip_port_list = valid_targets_dict[target][tpgt] KeyError: '' It still shows None instead of an empty field but you can continue. None value will be fixed as for https://bugzilla.redhat.com/show_bug.cgi?id=1541848 Can deploy HE with iSCSI with cockpit: Test version: cockpit-ws-157-1.el7.x86_64 cockpit-bridge-157-1.el7.x86_64 cockpit-storaged-157-1.el7.noarch cockpit-dashboard-157-1.el7.x86_64 cockpit-157-1.el7.x86_64 cockpit-ovirt-dashboard-0.11.10-0.1.el7ev.noarch cockpit-system-157-1.el7.noarch ovirt-hosted-engine-setup-2.2.9-1.el7ev.noarch ovirt-hosted-engine-ha-2.2.4-1.el7ev.noarch rhvh-4.2.1.2-0.20180202.0+1 rhvm-appliance-4.2-20180202.0.el7.noarch So, change the bug's status to verified! Move back to Modify status due to new patch imported Created attachment 1391788 [details]
scenario1_1
Created attachment 1391789 [details]
scenario1_2
Created attachment 1391790 [details]
scenario1_1_failed
Created attachment 1391791 [details]
scenario1_2_failed
Created attachment 1391804 [details]
scenario2
Created attachment 1391805 [details]
scenario2_1
Update: I have tested some scenarios with the latest version (cockpit-ovirt-dashboard-0.11.11-0.1.el7ev.noarch) 1. Finish the iscsi configuration on the storage page(user/password, target name, Lun) https://bugzilla.redhat.com/attachment.cgi?id=1391788 https://bugzilla.redhat.com/attachment.cgi?id=1391789 connect to the iscsi target (scenario1_1 is need to the user/password, scenario1_2 did't need the user/password) Result: The requested device is not listed by VDSM Failed to execute stage 'Environment customization': Cannot access LUN Hosted Engine deployment failed https://bugzilla.redhat.com/attachment.cgi?id=1391790 https://bugzilla.redhat.com/attachment.cgi?id=1391791 2. Just finish the iscsi target ip and port(didn't finish the user/password, target name, Lun) https://bugzilla.redhat.com/attachment.cgi?id=1391804 https://bugzilla.redhat.com/attachment.cgi?id=1391805 Result: list all iscsi target, select the used iscsi target , will enter the deployment process. So, change the bug's status to assigned. (In reply to Yihui Zhao from comment #15) > Update: > I have tested some scenarios with the latest version > (cockpit-ovirt-dashboard-0.11.11-0.1.el7ev.noarch) > > > > 1. Finish the iscsi configuration on the storage page(user/password, target > name, Lun) > https://bugzilla.redhat.com/attachment.cgi?id=1391788 > In destination LUN field you have the enter the LUN uuid and I don't think that 1 is a reasonable uuid. Can you please retry leaving that field empty in order to let otopi propose a selection menu for you? (In reply to Simone Tiraboschi from comment #17) > In destination LUN field you have the enter the LUN uuid and I don't think > that 1 is a reasonable uuid. > Can you please retry leaving that field empty in order to let otopi propose > a selection menu for you? I opened a new specific bug on LUN uuid validation. (In reply to Simone Tiraboschi from comment #17) > (In reply to Yihui Zhao from comment #15) > > Update: > > I have tested some scenarios with the latest version > > (cockpit-ovirt-dashboard-0.11.11-0.1.el7ev.noarch) > > > > > > > > 1. Finish the iscsi configuration on the storage page(user/password, target > > name, Lun) > > https://bugzilla.redhat.com/attachment.cgi?id=1391788 > > > > In destination LUN field you have the enter the LUN uuid and I don't think > that 1 is a reasonable uuid. > Can you please retry leaving that field empty in order to let otopi propose > a selection menu for you? let the destination LUN field empty, then deploy HE successfully. See the comment 15: 2. Just finish the iscsi target ip and port(didn't finish the user/password, target name, Lun) https://bugzilla.redhat.com/attachment.cgi?id=1391804 https://bugzilla.redhat.com/attachment.cgi?id=1391805 Result: list all iscsi target, select the used iscsi target , will enter the deployment process. Hey Yihui - Can we move this back to VERIFIED, then? Let's document this for beta, and release, with improved discovery values in 4.2.2 I'm going to rework this for 4.2.2 The iSCSI discovery flow should allow the following: (Optional) username password (Required) target address This is to be followed by two buttons: <Test> (to verify username/password works) <Discover> (get a list of targets and populate a dropdown) There is not enough time to complete this for 4.2.1, and it's not feasible to adequately resolve this by getting an actual listing of LUNs prior to 4.2.1, which leaves two options: * Completely disable all of these fields for now, leaving them blank, and let otopi succeed. * Document that users should input the IQN, which would be a reasonable assumption anyway. In the interest of shipping 4.2.1, I'd advocate for the latter. Yaniv? (In reply to Ryan Barry from comment #20) > Hey Yihui - > > Can we move this back to VERIFIED, then? > > Let's document this for beta, and release, with improved discovery values in > 4.2.2 Ryan, Simone filed a new bug to track the issue. And due to the release day coming, I think only document that users (for example, only input the target address for attempt). The new bug to track the "cockpit validation": https://bugzilla.redhat.com/show_bug.cgi?id=1542426 If consider to close it, I will change the status to verified when it becomes ON_QA. The new flow is definitively the ansible based one and the otopi one is just a fallback. On my opinion it doesn't make much sense to develop something new on cockpit side specific for the vintage otopi flow (neither for 4.2.2). I'd suggest to simply hide the iSCSI related fields on cockpit side and let otopi take over and focusing on a proper design of the iSCSI dialog (with multipath support) for the ansible based flow for 4.2.2. I agree, but the code for the wizard is mostly shared, so a 'proper' implementation of iSCSI discovery will affect both. (In reply to Ryan Barry from comment #24) > I agree, but the code for the wizard is mostly shared, so a 'proper' > implementation of iSCSI discovery will affect both. This is an issue by itself: on the new ansible flow we have a specific playbook that performs the iSCSI discovery using REST API, no need to directly deal with iscsiadm and multipath tools. This is exactly what's being used by IscsiUtil.js on the storage page (both flows heavily use Ansible to discover facts) My hope is to make this more interactive from the wizard, not to use iscsiadm According to the comment 22, change the bug's status to verified, about the "cockpit validation" , see the bug : https://bugzilla.redhat.com/show_bug.cgi?id=1542426 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. |