[Bug 1799648] [NEW] Fibre Channel attachments incorrectly scans for local WWN instead of target WWN (Upstream Backport)

[Trent Lloyd]

Public bug reported:

Attaching Fibre Channel disks fails in python-os-brick
1.15.2-0ubuntu1~cloud0 (xenial-pike) because it searches for the local
WWN instead of the remote WWN.

This has been fixed upstream:
https://review.openstack.org/#/c/520052/
https://bugs.launchpad.net/os-brick/+bug/1687607

We should SRU backport this to xenial-pike and all other relevant
versions required to get it that far back.

The change appears in os-brick 2.3.0 (Queens) and 1.15.2 (Pike) is the
immediately preceding version. To my understanding that should mean that
it is valid to backport it to the Xenial-Pike cloud archive only and no
other release.


[Full Upstream Change Description]
Fixing FC scanning

Current FC tries to limit the scanning range by detecting the target and
channel, unfortunately this code has a good number of implementation
issues:

- Matching uses local WWNN instead of target's WWPN.
- Not using a shell to run the command, so the * glob won't expand.
- Not using -l on grep command to list file names instead of contents.
- Not making the search case insensitive.

This patch fixes all these issues by using the target's WWPNs instead
-taking into account FC Zone/Access control information if present- and
supporting both possible connection information formats for the WWPNs
(single value or list of values).

Rescan tests have been modified to adhere to unit tests best practices,
where each test case only tests the specific code in the method under
test and mocks everything else.

[Impact]

 * Attaching Fibre Channel volumes fails completely without this patch
(at least with HP 3Par storage)

[Test Case]

 * Unfortunately as reproducing this requires Fibre Channel hardware it
is unlikely reproducible or testable in a test environment. However it
is reproduced simply by trying to attach a new FC volume from a HP 3Par
SAN.

[Regression Potential]

 * As this code changes how the FC searching works, there is definite
potential for regression as different SANs all work in slightly
different ways which is likely why this code was partly broken in the
first place.

 * Fortunately usage of Fibre Channel in deployments of Ubuntu OpenStack
is low and since the current code we are fixing here appears to be
factually incorrect (searching for the wrong WWN) it is likely this
functionality does not currently work at all. Therefor it is unlikely to
get worse however it is possible the changes interact with other
varieties of Fibre Channel SANs in ways I have not anticipated.

 * The backported patch is shipping upstream for ~12 months and applies
cleanly with no changes needed. I checked for other subsequent patches
which may have been needed to correct the relevant behavior. The only
subsequent FC/WWNN change appears to be to simply limit which ports are
scanned to try not to scan others unnecessarily. Which is mostly an
optimization.

[Other Info]

 * A customer production Xenial-Pike environment is affected so we can
test the fix there

** Affects: cloud-archive
     Importance: Undecided
         Status: New

** Affects: python-os-brick (Ubuntu)
     Importance: Undecided
         Status: New

** Also affects: cloud-archive
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to python-os-brick in Ubuntu.
https://bugs.launchpad.net/bugs/1799648

Title:
   Fibre Channel attachments incorrectly scans for local WWN instead of
  target WWN (Upstream Backport)

Status in Ubuntu Cloud Archive:
  New
Status in python-os-brick package in Ubuntu:
  New

Bug description:
  Attaching Fibre Channel disks fails in python-os-brick
  1.15.2-0ubuntu1~cloud0 (xenial-pike) because it searches for the local
  WWN instead of the remote WWN.

  This has been fixed upstream:
  https://review.openstack.org/#/c/520052/
  https://bugs.launchpad.net/os-brick/+bug/1687607

  We should SRU backport this to xenial-pike and all other relevant
  versions required to get it that far back.

  The change appears in os-brick 2.3.0 (Queens) and 1.15.2 (Pike) is the
  immediately preceding version. To my understanding that should mean
  that it is valid to backport it to the Xenial-Pike cloud archive only
  and no other release.

  
  [Full Upstream Change Description]
  Fixing FC scanning

  Current FC tries to limit the scanning range by detecting the target and
  channel, unfortunately this code has a good number of implementation
  issues:

  - Matching uses local WWNN instead of target's WWPN.
  - Not using a shell to run the command, so the * glob won't expand.
  - Not using -l on grep command to list file names instead of contents.
  - Not making the search case insensitive.

  This patch fixes all these issues by using the target's WWPNs instead
  -taking into account FC Zone/Access control information if present- and
  supporting both possible connection information formats for the WWPNs
  (single value or list of values).

  Rescan tests have been modified to adhere to unit tests best practices,
  where each test case only tests the specific code in the method under
  test and mocks everything else.

  [Impact]

   * Attaching Fibre Channel volumes fails completely without this patch
  (at least with HP 3Par storage)

  [Test Case]

   * Unfortunately as reproducing this requires Fibre Channel hardware
  it is unlikely reproducible or testable in a test environment. However
  it is reproduced simply by trying to attach a new FC volume from a HP
  3Par SAN.

  [Regression Potential]

   * As this code changes how the FC searching works, there is definite
  potential for regression as different SANs all work in slightly
  different ways which is likely why this code was partly broken in the
  first place.

   * Fortunately usage of Fibre Channel in deployments of Ubuntu
  OpenStack is low and since the current code we are fixing here appears
  to be factually incorrect (searching for the wrong WWN) it is likely
  this functionality does not currently work at all. Therefor it is
  unlikely to get worse however it is possible the changes interact with
  other varieties of Fibre Channel SANs in ways I have not anticipated.

   * The backported patch is shipping upstream for ~12 months and
  applies cleanly with no changes needed. I checked for other subsequent
  patches which may have been needed to correct the relevant behavior.
  The only subsequent FC/WWNN change appears to be to simply limit which
  ports are scanned to try not to scan others unnecessarily. Which is
  mostly an optimization.

  [Other Info]

   * A customer production Xenial-Pike environment is affected so we can
  test the fix there

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1799648/+subscriptions