Red Hat Bugzilla – Bug 1539391
iSCSI deployment of node zero sometimes fails with "Error: Fault reason is "Operation Failed". Fault detail is "[]". HTTP response code is 400."
Last modified: 2018-05-15 13:33:04 EDT
Created attachment 1387234 [details] sosreport from alma04 Description of problem: [ ERROR ] Error: Fault reason is "Operation Failed". Fault detail is "[]". HTTP response code is 400. [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Fault reason is \"Operation Failed\". Fault detail is \"[]\". HTTP response code is 400."} Version-Release number of selected component (if applicable): ovirt-hosted-engine-ha-2.2.5-0.0.master.20180125081710.20180125081707.git6046986.el7.centos.noarch ovirt-hosted-engine-setup-2.2.9-0.0.master.20180124164059.git097610a.el7.centos.noarch ovirt-engine-appliance-4.2-20180127.1.el7.centos.noarch How reproducible: 100% Steps to Reproduce: 1.Deploy SHE using ansible over iSCSI. Actual results: Deployment fails. Expected results: Should be successful. Additional info: Sosreport from host is attached.
Does the vintage deployment on the same setup work? Can you share the the answer file?
(In reply to Yaniv Kaul from comment #1) > Does the vintage deployment on the same setup work? > Can you share the the answer file? Answer file? Isn't it appears within the sosreport? I did only deployment using ansible and did not done it using regular yet.
Can you add the logs from the engine vm?
As Simone couldn't reproduce on dev, lowering priority/severity.
Can you please attach engine.log from the engine VM?
(In reply to Simone Tiraboschi from comment #8) > Can you please attach engine.log from the engine VM? There was no engine log, engine was not accessible via ssh.
Unfortunately on failures the error message from the engine is not that clear: 2018-02-12 16:08:55,230+0200 DEBUG ansible on_any args (TASK: Add iSCSI storage domain,) kwargs {'is_conditional': False} 2018-02-12 16:08:57,396+0200 DEBUG var changed: host "localhost" var "otopi_storage_domain_details" type "<type 'dict'>" value: "{u'failed': True, u'exception': u'Traceback (most recent call last):\n File "/tmp/ansible_tfDPAc/ansible_module_ovirt_storage_domains.py", line 541, in main\n sd_id = storage_domains_module.create()[\'id\']\n File "/tmp/ansible_tfDPAc/ansible_modlib.zip/ansible/module_utils/ovirt.py", line 573, in create\n self.build_entity(),\n File "/tmp/ansible_tfDPAc/ansible_module_ovirt_storage_domains.py", line 289, in build_entity\n self._login(storage_type, storage)\n File "/tmp/ansible_tfDPAc/ansible_module_ovirt_storage_domains.py", line 282, in _login\n target=storage.get(\'target\'),\n File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 36435, in iscsi_login\n return self._internal_action(action, \'iscsilogin\', None, headers, query, wait)\n File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 299, in _internal_action\n return future.wait() if wait else future\n File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 55, in wait\n return self._code(response)\n File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 296, in callback\n self._check_fault(response)\n File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 134, in _check_fault\n self._raise_error(response, body.fault)\n File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 118, in _raise_error\n raise error\nError: Fault reason is "Operation Failed". Fault detail is "[]". HTTP response code is 400.\n', 'changed': False, u'msg': u'Fault reason is "Operation Failed". Fault detail is "[]". HTTP response code is 400.'}"
From vdsm logs it seams just an iSCSI login error
Created attachment 1394936 [details] sosreport from the engine
Now iSCSI deployment is working with these components: Works for me on these components on host: rhvm-appliance-4.2-20180202.0.el7.noarch ovirt-hosted-engine-ha-2.2.5-1.el7ev.noarch ovirt-hosted-engine-setup-2.2.10-1.el7ev.noarch Red Hat Enterprise Linux Server release 7.4 (Maipo) Linux 3.10.0-693.19.1.el7.x86_64 #1 SMP Thu Feb 1 12:34:44 EST 2018 x86_64 x86_64 x86_64 GNU/Linux
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:1471