Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1475122

Summary: RESTAPI- DELETE a storage connection from ISCSI SD in maintenance - response 500 internal server error
Product: [oVirt] ovirt-engine Reporter: Avihai <aefrat>
Component: BLL.StorageAssignee: Maor <mlipchuk>
Status: CLOSED CURRENTRELEASE QA Contact: Avihai <aefrat>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.2.0CC: amureini, bugs
Target Milestone: ovirt-4.2.0Keywords: AutomationTriaged
Target Release: ---Flags: rule-engine: ovirt-4.2+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-20 10:50:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
engine , vdsm logs and REST response print screen none

Description Avihai 2017-07-26 06:30:38 UTC
Created attachment 1304602 [details]
engine , vdsm logs and REST response print screen

Description of problem:
RESTAPI- DELETE a storage connection from ISCSI SD in maintenance  - response 500 internal server error although connection is deleted

Version-Release number of selected component (if applicable):
Engine - 4.2.0-0.0.master.20170723141021.git463826a.el7.centos
VDSM - 4.20.1-232.gitca44245.el7.centos.x86_64

How reproducible:
100%

Steps to Reproduce:
1) Create&activate 2 SD's :
1 Master SD NFS & additional Non master ISCSI SD
 
2) change iscsi SD to maintenance (deactivate SD ) manual or via rest API :

Operation = POST
URL:
https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/datacenters/ca21c068-eb68-4da4-8111-4cdb91de191e/storagedomains/2af51fad-b583-4777-a306-0964153558a3/deactivate
3add5/deactivate body /deactivate 

body:
<action>
    <async>false</async>
    <grace_period>
        <expiry>10</expiry>
    </grace_period>
</action>


3) Check for existing ISCSI SD connections via url & see 1 connection exist-> https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/storagedomains/2af51fad-b583-4777-a306-0964153558a3/storageconnections

The following response is given ( 1 connection exist )  :
<storage_connections>
<storage_connection href="/ovirt-engine/api/storageconnections/167b8591-a933-4a1b-ac06-a9cd7d24b0e3" id="167b8591-a933-4a1b-ac06-a9cd7d24b0e3">
<address>10.35.146.129</address>
<port>3260</port>
<target>
iqn.2008-05.com.xtremio:xio00153500071-514f0c50023f6c00
</target>
<type>iscsi</type>
</storage_connection>
</storage_connections>


4) Via REST API perform DELET storage connection session:


Request:
operation = DELETE 
URL =https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/storagedomains/2af51fad-b583-4777-a306-0964153558a3/storageconnections/167b8591-a933-4a1b-ac06-a9cd7d24b0e3
Body = Empty


Actual results:
Session is delete (as expected) BUT the RESTAPI response is error Internal Server Error (500) instead  of success .

Response:
<html>
    <head>
        <title>Error</title>
    </head>
    <body>Internal Server Error</body>
</html>

response body :
Could not find MessageBodyWriter for response object of type: org.ovirt.engine.api.model.Action of media type: application/octet-stream


Expected results:
Session should be deleted & No Error should occur.


Additional info:
Checking storage connection on that SD again you can see connection was removed as expected.

Engine
2017-07-26 08:46:00,270+03 WARN  [org.ovirt.engine.core.dal.job.ExecutionMessageDirector] (default task-1) [50fce781-3e6b-4a60-81c2-e03b1bc44f5c] The message key 'DetachStorageConnectionFromStorageDomain' is missing from 'bundles/ExecutionMessages'



VDSM:
2017-07-26 08:41:44,837+0300 INFO  (jsonrpc/5) [vdsm.api] START disconnectStorageServer(domType=3, spUUID='ca21c068-eb68-4da4-8111-4cdb91de191e', conList=[{'id': '167b8591-a933-4a1b-ac06-a9cd7d24b0e3', 'connection': '10.35.146.129', 'iqn': 'iqn.2008-05.com.xtremio:xio00153500071-514f0c50023f6c00', 'user': u'', 'tpgt': '1', 'password': '********', 'port': '3260'}], options=None) from=::ffff:10.35.161.118,53072, flow_id=663d10cf, task_id=9f49c222-f171-41ff-85b4-ead1297e2f5b (api:46)
2017-07-26 08:41:45,465+0300 WARN  (monitor/54a8266) [storage.Multipath] Map '3514f0c5a51600268' has no slaves (multipath:107)
2017-07-26 08:41:46,235+0300 INFO  (jsonrpc/5) [vdsm.api] FINISH disconnectStorageServer return={'statuslist': [{'status': 0, 'id': '167b8591-a933-4a1b-ac06-a9cd7d24b0e3'}]} from=::ffff:10.35.161.118,53072, flow_id=663d10cf, task_id=9f49c222-f171-41ff-85b4-ead1297e2f5b (api:52)
2017-07-26 08:41:46,533+0300 WARN  (monitor/b3947b5) [storage.Multipath] Map '3514f0c5a51600268' has no slaves (multipath:107)
2017-07-26 08:57:34,535+0300 INFO  (jsonrpc/6) [vdsm.api] START disconnectStorageServer(domType=3, spUUID='ca21c068-eb68-4da4-8111-4cdb91de191e', conList=[{'id': '167b8591-a933-4a1b-ac06-a9cd7d24b0e3', 'connection': '10.35.146.129', 'iqn': 'iqn.2008-05.com.xtremio:xio00153500071-514f0c50023f6c00', 'user': u'', 'tpgt': '1', 'password': '********', 'port': '3260'}], options=None) from=::ffff:10.35.161.118,53072, flow_id=72584289, task_id=751ebf33-4c1b-490f-b64d-082c601a2556 (api:46)
2017-07-26 08:57:35,546+0300 INFO  (jsonrpc/6) [vdsm.api] FINISH disconnectStorageServer return={'statuslist': [{'status': 0, 'id': '167b8591-a933-4a1b-ac06-a9cd7d24b0e3'}]} from=::ffff:10.35.161.118,53072, flow_id=72584289, task_id=751ebf33-4c1b-490f-b64d-082c601a2556 (api:52)

Comment 1 Avihai 2017-07-26 07:57:42 UTC
This issue is not a new issue (not regression), occur also in 4.1.

Comment 2 Avihai 2017-08-07 11:26:11 UTC
verified at  4.2.0-0.0.master.20170803140556.git1e7d0dd.el7.centos.

This issue is not seen anymore & the 500 server error failure is gone.
However, a new issue is seen as detaching a connection which is also used from a another SD - Opened Bug 1478869 on this issue.

Comment 3 Sandro Bonazzola 2017-12-20 10:50:39 UTC
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.