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

[Ubuntu Foundations Team Bug Bot]

The attachment "lp1799648-fix-fc-scanning.patch" seems to be a debdiff.
The ubuntu-sponsors team has been subscribed to the bug report so that
they can review and hopefully sponsor the debdiff.  If the attachment
isn't a patch, please remove the "patch" flag from the attachment,
remove the "patch" tag, and if you are member of the ~ubuntu-sponsors,
unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issue please contact him.]

** Tags added: patch

-- 
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