Multipath not flushed when friendly names are enabled

[Gorka Eguileor]

When we are using friendly names for multipath the multipaths are not getting flushed, which may lead to data loss on slow connections and multipath entries with no actual paths.

This happens in both iSCSI and FC connections, and it is due to the flush being requested on the WWN instead of the actual name of the device.

So when we are not using friendly names the WWN and the device name are the same and our call to multipath -f will successfully flush remaining data, but when we are using friendly names they will not match, and the call to multipath -f will silently fail (return code 0) and the flush will not actually go through. When the flush doesn't happen, if there is remaining data, then the multipath will stay once the individual paths have been removed.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/433102

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/433102
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=c0640ce13727e97832049f1d68744e715c3fa031
Submitter: Jenkins
Branch: master

commit c0640ce13727e97832049f1d68744e715c3fa031
Author: Gorka Eguileor <email address hidden>
Date: Sat Feb 11 20:58:08 2017 +0100

    Fix multipath flush when using friendly names

    When we are using friendly names for multipath the multipaths are not
    getting flushed, which may lead to data loss on slow connections and
    multipath entries with no actual paths.

    This happens in both iSCSI and FC connections, and it is due to the
    flush being requested on the WWN instead of the actual name of the
    device.

    So when we are not using friendly names the WWN and the device name are
    the same and our call to multipath -f will successfully flush remaining
    data, but when we are using friendly names they will not match, and the
    call to multipath -f will silently fail (return code 0) and the flush
    will not actually go through. When the flush doesn't happen, if there is
    remaining data, then the multipath will stay once the individual paths
    have been removed.

    Closes-Bug: #1663925
    Change-Id: Ib93d945a5b5fca57bcac4e176d62d1412b95f2da

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/ocata
Review: https://review.openstack.org/445941

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/445941
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=cbeb89933c57b9e9756c460fa07aab254b15078d
Submitter: Jenkins
Branch: stable/ocata

commit cbeb89933c57b9e9756c460fa07aab254b15078d
Author: Gorka Eguileor <email address hidden>
Date: Sat Feb 11 20:58:08 2017 +0100

    Fix multipath flush when using friendly names

    When we are using friendly names for multipath the multipaths are not
    getting flushed, which may lead to data loss on slow connections and
    multipath entries with no actual paths.

    This happens in both iSCSI and FC connections, and it is due to the
    flush being requested on the WWN instead of the actual name of the
    device.

    So when we are not using friendly names the WWN and the device name are
    the same and our call to multipath -f will successfully flush remaining
    data, but when we are using friendly names they will not match, and the
    call to multipath -f will silently fail (return code 0) and the flush
    will not actually go through. When the flush doesn't happen, if there is
    remaining data, then the multipath will stay once the individual paths
    have been removed.

    Closes-Bug: #1663925
    Change-Id: Ib93d945a5b5fca57bcac4e176d62d1412b95f2da
    (cherry picked from commit c0640ce13727e97832049f1d68744e715c3fa031)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/os-brick 1.12.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/os-brick 1.11.1 release.