Bug 1426442

Summary:	os-brick does not cleanup failed iSCSi sessions it created
Product:	Red Hat OpenStack	Reporter:	Yuming Ma <yumima>
Component:	python-os-brick	Assignee:	Gorka Eguileor <geguileo>
Status:	CLOSED ERRATA	QA Contact:	Avi Avraham <aavraham>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	8.0 (Liberty)	CC:	apevec, charcrou, eharney, geguileo, jdonohue, jschluet, jwaterwo, lhh, mburns, mlopes, nlevinki, pgrist, wlehman
Target Milestone:	zstream	Keywords:	Triaged, ZStream
Target Release:	8.0 (Liberty)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	hot
Fixed In Version:	python-os-brick-0.5.0-4.el7ost	Doc Type:	Bug Fix
Doc Text:	This update contains a complete refactoring of the iSCSI connection mechanism, resulting in improved reliability. For optimal results, use with openstack-cinder >= 7.0.3-8 and iscsi-initiator-utils >= 6.2.0.874-2.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-10-25 17:06:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1194008

Comment 1 Yuming Ma 2017-02-23 22:54:38 UTC

This will need to be:
1. merged to upstream
2. back port to OSP8

Comment 2 Yuming Ma 2017-02-28 22:25:37 UTC

Description of problem:

Its possible for an iSCSi connection to fail after login to the lun is successful. If multipath -r is run when the session is failed it will not be included in the multipath device. As a result the call to remove_multipath_device will not remove the underlying iSCSi device. As such we need to ensure that we have deleted all luns that we logged into before we call _disconnect_volume_multipath_iscsi. Link to review: https://review.openstack.org/#/c/409895/

This will need to be:
1. merged to upstream
2. back port to OSP

Comment 3 Yuming Ma 2017-03-02 23:01:53 UTC

William and Gorka,

Just to let you know that the proposed change seems not working well with the comprehensive change (multiple-changes) you posted while ago for the migration issue. 

This is how to reproduce the problem:
1. insert package drop to hypervisor and cinder volumes server, e.g.
sudo iptables -s <source> -I master-filter-pre-INPUT -m statistic --mode random --probability 0.2 -j DROP

2. create/delete volume,  attach/detach, and live-migration instances

3. observer the failure due to connection failure

We may beed to carefully review all the problems together with the migration issue and come up with a comprehensive solution for all

Comment 4 Charles Crouch 2017-03-03 00:50:12 UTC

s/insert package/insert packet/

Comment 10 William 2017-07-31 19:55:30 UTC

Customer has requested that we make more public updates so they have visibility into bugs and they don't need to wait for support to update cases.

Customer has also requested link to upstream bugs so they can track their progress and stay out of our hair.

Comment 13 Avi Avraham 2017-10-18 12:56:23 UTC

verified
Package installed : 
python-os-brick-0.5.0-4.el7ost.noarch
Environment setup includes XtremIO connected with 2 path ISCSI as backend 
Need to run tests on specific storage backend for relevant setup to verify the fix.

Comment 15 errata-xmlrpc 2017-10-25 17:06:46 UTC

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-2017:3067