Bug 1543424 - [vintage][iscsi][multipath] With answerfile (or from cockpit) the setup fails if just one of the paths to the storage server is down
Summary: [vintage][iscsi][multipath] With answerfile (or from cockpit) the setup fails...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-hosted-engine-setup
Classification: oVirt
Component: Plugins.Block
Version: 2.2.6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.2.2
: ---
Assignee: Simone Tiraboschi
QA Contact: Nikolai Sednev
URL:
Whiteboard:
Depends On:
Blocks: 1458709
TreeView+ depends on / blocked
 
Reported: 2018-02-08 12:58 UTC by Simone Tiraboschi
Modified: 2018-04-05 09:38 UTC (History)
8 users (show)

Fixed In Version: ovirt-hosted-engine-setup-2.2.10
Clone Of:
Environment:
Last Closed: 2018-04-05 09:38:44 UTC
oVirt Team: Integration
Embargoed:
rule-engine: ovirt-4.2+
rule-engine: exception+
sbonazzo: devel_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 87341 0 master MERGED vintage: iscsi: avoid failing the setup if just one path is down 2018-09-03 09:35:45 UTC
oVirt gerrit 87350 0 master MERGED iscsi: avoid failing if just one path is down 2018-02-13 10:22:52 UTC
oVirt gerrit 87547 0 ovirt-hosted-engine-setup-2.2 MERGED vintage: iscsi: avoid failing the setup if just one path is down 2018-02-13 14:50:05 UTC
oVirt gerrit 87585 0 v2.2.z MERGED iscsi: avoid failing if just one path is down 2018-02-13 17:03:42 UTC

Description Simone Tiraboschi 2018-02-08 12:58:13 UTC
Description of problem:
Trying to deploy hosted-engine on iSCSI with multi-path on the vintage flow,
the setup could fail if just one of the path to the storage server is down.

In interactive mode the setup will check active paths at customization stage,
but if the path list is provided via answer file (from cockpit for instance) the setup will try consume all of them failing if just a path is down with:

2018-02-08 13:14:25,449+0100 DEBUG otopi.plugins.gr_he_setup.storage.storage storage._storageServerConnection:328 StoragePool.connectStorageServer
2018-02-08 13:18:28,538+0100 DEBUG otopi.plugins.gr_he_setup.storage.storage storage._storageServerConnection:404 [{u'status': 0, u'id': u'880d3535-9fb8-444c-a24d-dcfc220e9887'}, {u'status': 465, u'id': u'880d3535-9fb8-444c-a24d-dcfc220e9887'}, {u'status': 465, u'id': u'880d3535-9fb8-444c-a24d-dcfc220e9887'}]
2018-02-08 13:18:28,539+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/storage.py", line 949, in _misc
    self._storageServerConnection()
  File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-setup/storage/storage.py", line 412, in _storageServerConnection
    _('Connection to storage server failed')
RuntimeError: Connection to storage server failed


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


How reproducible:
100%

Steps to Reproduce:
1. try to deploy hosted-engine from cockpit specifying more than one iSCSI portal separating them with a comma (192.168.1.125,192.168.2.125,192.168.3.125)
2. one portal can be reached but at least one of the remaining is down
3.

Actual results:
The setup fails with
  RuntimeError: Connection to storage server failed
also if just one of the iSCSI portal is not reachable

Expected results:
The setup will emit a warning about failed paths and it will continue if at a path is working

Additional info:

Comment 2 Nikolai Sednev 2018-04-01 14:48:10 UTC
Works for me on these components:
ovirt-hosted-engine-ha-2.2.9-1.el7ev.noarch
ovirt-hosted-engine-setup-2.2.15-1.el7ev.noarch
rhvm-appliance-4.2-20180202.0.el7.noarch
Linux 3.10.0-862.el7.x86_64 #1 SMP Wed Mar 21 18:14:51 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 7.5 (Maipo)

Comment 3 Sandro Bonazzola 2018-04-05 09:38:44 UTC
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.


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