[SRU] multipath iscsi does not logout of sessions on xenial
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu Cloud Archive |
Fix Released
|
Medium
|
Unassigned | ||
Mitaka |
Fix Released
|
Medium
|
Unassigned | ||
Newton |
Fix Released
|
Medium
|
Unassigned | ||
os-brick |
Fix Released
|
Undecided
|
Unassigned | ||
python-os-brick (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Xenial |
Fix Released
|
Medium
|
Hua Zhang | ||
Yakkety |
Fix Released
|
Medium
|
Unassigned |
Bug Description
[Impact]
* multipath-tools has a bug that 'multipath -r' can cause /dev/mapper/<wwid> to be deleted and re-created momentarily (bug #1621340 is used to track this problem), thus os.stat(mdev) right after _rescan_multipath ('multipath -r') in os-brick can fail if it is executed before multipath dev being re-created. This will also lead to multipath iscsi does not logout of sessions on xenial.
[Test Case]
* Enable cinder multipath by adding iscsi_ip_address and iscsi_secondary
* Enable nova multipath by adding iscsi_use_
* Detach a iSCSI volume
* Check that devices/symlinks do not get messed up mentioned below, or check that multipath device /dev/mapper/<wwid> doesn't be deleted and re-created momentarily
[Regression Potential]
* multipath-tools loads devices on its own, we shouldn't need to be forcing multipathd to do reload, so there is no regression potential.
stack@xenial-
tcp: [5] 10.0.1.10:3260,1 iqn.2010-
tcp: [6] 10.0.5.10:3260,1 iqn.2010-
tcp: [7] 10.0.1.11:3260,1 iqn.2010-
tcp: [8] 10.0.5.11:3260,1 iqn.2010-
stack@xenial-
10.0.1.11:3260,-1 iqn.2010-
10.0.5.11:3260,-1 iqn.2010-
10.0.5.10:3260,-1 iqn.2010-
10.0.1.10:3260,-1 iqn.2010-
stack@xenial-
Sep 14 22:33:14 xenial-qemu-tester multipath: dm-0: failed to get udev uid: Invalid argument
Sep 14 22:33:14 xenial-qemu-tester multipath: dm-0: failed to get sysfs uid: Invalid argument
Sep 14 22:33:14 xenial-qemu-tester multipath: dm-0: failed to get sgio uid: No such file or directory
Sep 14 22:33:14 xenial-qemu-tester systemd[1347]: dev-disk-
Sep 14 22:33:14 xenial-qemu-tester systemd[1347]: dev-disk-
Sep 14 22:33:14 xenial-qemu-tester systemd[1]: dev-disk-
Sep 14 22:33:14 xenial-qemu-tester systemd[1]: dev-disk-
Sep 14 22:33:14 xenial-qemu-tester kernel: [22362.163521] audit: type=1400 audit(147389239
Sep 14 22:33:14 xenial-qemu-tester kernel: [22362.173614] audit: type=1400 audit(147389239
Sep 14 22:33:14 xenial-qemu-tester iscsid: Connection8:0 to [target: iqn.2010-
stack@xenial-
stack@xenial-
tcp: [5] 10.0.1.10:3260,1 iqn.2010-
tcp: [6] 10.0.5.10:3260,1 iqn.2010-
tcp: [7] 10.0.1.11:3260,1 iqn.2010-
tcp: [8] 10.0.5.11:3260,1 iqn.2010-
stack@xenial-
Sep 14 22:48:10 xenial-qemu-tester kernel: [23257.736455] connection6:0: detected conn error (1020)
Sep 14 22:48:13 xenial-qemu-tester kernel: [23260.742036] connection5:0: detected conn error (1020)
Sep 14 22:48:13 xenial-qemu-tester kernel: [23260.742066] connection7:0: detected conn error (1020)
Sep 14 22:48:13 xenial-qemu-tester kernel: [23260.742139] connection8:0: detected conn error (1020)
Sep 14 22:48:13 xenial-qemu-tester kernel: [23260.742156] connection6:0: detected conn error (1020)
Sep 14 22:48:16 xenial-qemu-tester kernel: [23263.747638] connection5:0: detected conn error (1020)
Sep 14 22:48:16 xenial-qemu-tester kernel: [23263.747666] connection7:0: detected conn error (1020)
Sep 14 22:48:16 xenial-qemu-tester kernel: [23263.747710] connection8:0: detected conn error (1020)
Sep 14 22:48:16 xenial-qemu-tester kernel: [23263.747737] connection6:0: detected conn error (1020)
Sep 14 22:48:16 xenial-qemu-tester iscsid: message repeated 67 times: [ conn 0 login rejected: initiator failed authorization with target]
Sep 14 22:48:19 xenial-qemu-tester kernel: [23266.753999] connection6:0: detected conn error (1020)
Sep 14 22:48:19 xenial-qemu-tester kernel: [23266.754019] connection8:0: detected conn error (1020)
Sep 14 22:48:19 xenial-qemu-tester kernel: [23266.754105] connection5:0: detected conn error (1020)
Sep 14 22:48:19 xenial-qemu-tester kernel: [23266.754146] connection7:0: detected conn error (1020)
Changed in python-os-brick (Ubuntu): | |
status: | New → Invalid |
no longer affects: | python-os-brick (Ubuntu) |
Changed in python-os-brick (Ubuntu): | |
status: | New → Invalid |
Changed in python-os-brick (Ubuntu Xenial): | |
assignee: | nobody → Hua Zhang (zhhuabj) |
Changed in python-os-brick (Ubuntu): | |
status: | Invalid → Fix Released |
Changed in python-os-brick (Ubuntu Xenial): | |
status: | New → In Progress |
Changed in python-os-brick (Ubuntu): | |
importance: | Undecided → Medium |
Changed in python-os-brick (Ubuntu Xenial): | |
importance: | Undecided → Medium |
tags: | added: sts sts-sponsor ubuntu-sponsors |
Changed in python-os-brick (Ubuntu Yakkety): | |
importance: | Undecided → Medium |
status: | New → Triaged |
tags: |
added: sts-sru-needed removed: sts-sru ubuntu-sponsors |
tags: | removed: sts-sponsor |
Reviewed: https:/ /review. openstack. org/374421 /git.openstack. org/cgit/ openstack/ os-brick/ commit/ ?id=e591bc78cc0 1c1171060dc1539 9a46ff800b49c3
Committed: https:/
Submitter: Jenkins
Branch: master
commit e591bc78cc01c11 71060dc15399a46 ff800b49c3
Author: Patrick East <email address hidden>
Date: Wed Sep 21 15:05:48 2016 -0700
Stop calling multipath -r when attaching/detaching iSCSI volumes
Looking into this more there isn't any documented reason why we do this,
and on Ubuntu 16.04 there are issues with timing and devices/symlinks
getting messed up when we do the reload of device maps. We shouldn't
need to be forcing multipathd to do this, it loads devices on its own.
We'll leave in the one in 'wait_for_rw(..)' for now because there is /access. redhat. com/documentati on/en-US/ Red_Hat_ Enterprise 6/html/ Storage_ Administration_ Guide/ch37s04s0 2.html
some evidence that you may need to call it to update the rw state of
the multipath devices, see:
https:/
_Linux/
Change-Id: Iec58284abdc9bc bf99df5d07289bb 9d60a3554d7
Closes-Bug: #1623700