os-brick

FC scan too broad (regression)

Bug #1849504 reported by Gorka Eguileor
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
os-brick
Fix Released
Undecided
Gorka Eguileor

Bug Description

After some changes to the FC connector we have introduced a regression on the way we do the scans, and we end up scanning using wildcards even though we shouldn't.

The issue originates, as always, from the different interpretations that Cinder drivers do of the "initiator_target_map" key in the connection information.

Some consider this to be a mapping of what host ports can connect to what array ports, whereas for others is the ports that have been authorized (regardless of whether they can access or not).

With the current code, if we have the following connections:

HBA host7 ---- SWITCH ---- port W (channel 0, target 2)
          \--- SWITCH ---- port X (channel 0, target 3)

HBA host8 ---- SWITCH ---- port Y (channel 0, target 2)
          \--- SWITCH ---- port Z (channel 0, target 3)

We will end up with the following scans 8 scans for LUN L:

  - - L > host7
  - - L > host7
  0 2 L > host7
  0 3 L > host7

  0 2 L > host8
  0 3 L > host8
  - - L > host8
  - - L > host8

Which correspond to the responses from _get_hba_channel_scsi_target like this:

               port Y port Z port W port X
  host7 ... ['-','-',L] ['-','-',L] ['0','2',L] ['0','3',L]
  host8 ... ['0','2',L] ['0','3',L] ['-','-',L] ['-','-',L]

And we should only be doing 4 scans:

  0 2 L > host7
  0 3 L > host7
  0 2 L > host8
  0 3 L > host8

This bug is related to bugs: #1765000 and #1828440

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-brick (master)

Fix proposed to branch: master
Review: https://review.opendev.org/690640

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (master)

Reviewed: https://review.opendev.org/690640
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=708733e49598145eb8e898d486723dc3df00a52f
Submitter: Zuul
Branch: master

commit 708733e49598145eb8e898d486723dc3df00a52f
Author: Gorka Eguileor <email address hidden>
Date: Mon Oct 14 16:42:22 2019 +0200

    Fix FC scan too broad

    After some changes to the FC connector we have introduced a regression
    on the way we do the scans, and we end up scanning using wildcards even
    though we shouldn't.

    The targets in the "initiator_target_map" don't mean that they are all
    connected, so we must take that into account.

    With the current code, if we have the following connections:

    HBA host7 ---- SWITCH ---- port W (channel 0, target 2)
              \--- SWITCH ---- port X (channel 0, target 3)

    HBA host8 ---- SWITCH ---- port Y (channel 0, target 2)
              \--- SWITCH ---- port Z (channel 0, target 3)

    We will end up with the following scans 8 scans for LUN L:

      - - L > host7
      - - L > host7
      0 2 L > host7
      0 3 L > host7

      0 2 L > host8
      0 3 L > host8
      - - L > host8
      - - L > host8

    Which correspond to the responses from _get_hba_channel_scsi_target like
    this:

                   port Y port Z port W port X
      host7 ... ['-','-',L] ['-','-',L] ['0','2',L] ['0','3',L]
      host8 ... ['0','2',L] ['0','3',L] ['-','-',L] ['-','-',L]

    And we should only be doing 4 scans:

      0 2 L > host7
      0 3 L > host7
      0 2 L > host8
      0 3 L > host8

    Most storage arrays get their target ports automatically detected by the
    Linux FC initiator and sysfs gets populated with that information, but
    there are some that don't.

    We'll do a narrow scan using the channel, target, and LUN for the former
    and a wider scan for the latter.

    If all paths to a former type of array were down on the system boot the
    array could look like it's of the latter type and make us bring us
    unwanted volumes into the system by doing a broad scan.

    To prevent this from happening Cinder drivers can use the
    "enable_wildcard_scan" key in the connection information to let us know
    they don't want us to do broad scans even if no target ports are found
    (because they know the cause is there's no connection).

    Close-Bug: #1849504
    Related-Bug: #1765000
    Related-Bug: #1828440
    Change-Id: I5dbefaff43fb902b15117b443fc92f7b6a6ad8c9

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-brick (stable/train)

Fix proposed to branch: stable/train
Review: https://review.opendev.org/694314

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (stable/train)

Reviewed: https://review.opendev.org/694314
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=c76b6dc514b8e17e1211e4a7465a7e2a635adea3
Submitter: Zuul
Branch: stable/train

commit c76b6dc514b8e17e1211e4a7465a7e2a635adea3
Author: Gorka Eguileor <email address hidden>
Date: Mon Oct 14 16:42:22 2019 +0200

    Fix FC scan too broad

    After some changes to the FC connector we have introduced a regression
    on the way we do the scans, and we end up scanning using wildcards even
    though we shouldn't.

    The targets in the "initiator_target_map" don't mean that they are all
    connected, so we must take that into account.

    With the current code, if we have the following connections:

    HBA host7 ---- SWITCH ---- port W (channel 0, target 2)
              \--- SWITCH ---- port X (channel 0, target 3)

    HBA host8 ---- SWITCH ---- port Y (channel 0, target 2)
              \--- SWITCH ---- port Z (channel 0, target 3)

    We will end up with the following scans 8 scans for LUN L:

      - - L > host7
      - - L > host7
      0 2 L > host7
      0 3 L > host7

      0 2 L > host8
      0 3 L > host8
      - - L > host8
      - - L > host8

    Which correspond to the responses from _get_hba_channel_scsi_target like
    this:

                   port Y port Z port W port X
      host7 ... ['-','-',L] ['-','-',L] ['0','2',L] ['0','3',L]
      host8 ... ['0','2',L] ['0','3',L] ['-','-',L] ['-','-',L]

    And we should only be doing 4 scans:

      0 2 L > host7
      0 3 L > host7
      0 2 L > host8
      0 3 L > host8

    Most storage arrays get their target ports automatically detected by the
    Linux FC initiator and sysfs gets populated with that information, but
    there are some that don't.

    We'll do a narrow scan using the channel, target, and LUN for the former
    and a wider scan for the latter.

    If all paths to a former type of array were down on the system boot the
    array could look like it's of the latter type and make us bring us
    unwanted volumes into the system by doing a broad scan.

    To prevent this from happening Cinder drivers can use the
    "enable_wildcard_scan" key in the connection information to let us know
    they don't want us to do broad scans even if no target ports are found
    (because they know the cause is there's no connection).

    Close-Bug: #1849504
    Related-Bug: #1765000
    Related-Bug: #1828440
    Change-Id: I5dbefaff43fb902b15117b443fc92f7b6a6ad8c9
    (cherry picked from commit 708733e49598145eb8e898d486723dc3df00a52f)

tags: added: in-stable-train
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-brick (stable/stein)

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/694890

Revision history for this message
Eric Harney (eharney) wrote :

Commit message had "Close-Bug" tag instead of "Closes-Bug", so the launchpad integration didn't fully work.

Changed in os-brick:
status: New → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (stable/stein)

Reviewed: https://review.opendev.org/694890
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=8933503041529978b9fd816e1788b1b0c343b540
Submitter: Zuul
Branch: stable/stein

commit 8933503041529978b9fd816e1788b1b0c343b540
Author: Gorka Eguileor <email address hidden>
Date: Mon Oct 14 16:42:22 2019 +0200

    Fix FC scan too broad

    After some changes to the FC connector we have introduced a regression
    on the way we do the scans, and we end up scanning using wildcards even
    though we shouldn't.

    The targets in the "initiator_target_map" don't mean that they are all
    connected, so we must take that into account.

    With the current code, if we have the following connections:

    HBA host7 ---- SWITCH ---- port W (channel 0, target 2)
              \--- SWITCH ---- port X (channel 0, target 3)

    HBA host8 ---- SWITCH ---- port Y (channel 0, target 2)
              \--- SWITCH ---- port Z (channel 0, target 3)

    We will end up with the following scans 8 scans for LUN L:

      - - L > host7
      - - L > host7
      0 2 L > host7
      0 3 L > host7

      0 2 L > host8
      0 3 L > host8
      - - L > host8
      - - L > host8

    Which correspond to the responses from _get_hba_channel_scsi_target like
    this:

                   port Y port Z port W port X
      host7 ... ['-','-',L] ['-','-',L] ['0','2',L] ['0','3',L]
      host8 ... ['0','2',L] ['0','3',L] ['-','-',L] ['-','-',L]

    And we should only be doing 4 scans:

      0 2 L > host7
      0 3 L > host7
      0 2 L > host8
      0 3 L > host8

    Most storage arrays get their target ports automatically detected by the
    Linux FC initiator and sysfs gets populated with that information, but
    there are some that don't.

    We'll do a narrow scan using the channel, target, and LUN for the former
    and a wider scan for the latter.

    If all paths to a former type of array were down on the system boot the
    array could look like it's of the latter type and make us bring us
    unwanted volumes into the system by doing a broad scan.

    To prevent this from happening Cinder drivers can use the
    "enable_wildcard_scan" key in the connection information to let us know
    they don't want us to do broad scans even if no target ports are found
    (because they know the cause is there's no connection).

    Close-Bug: #1849504
    Related-Bug: #1765000
    Related-Bug: #1828440
    Change-Id: I5dbefaff43fb902b15117b443fc92f7b6a6ad8c9
    (cherry picked from commit 708733e49598145eb8e898d486723dc3df00a52f)
    (cherry picked from commit c76b6dc514b8e17e1211e4a7465a7e2a635adea3)

tags: added: in-stable-stein
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-brick (stable/queens)

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/696385

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to os-brick (stable/rocky)

Fix proposed to branch: stable/rocky
Review: https://review.opendev.org/697133

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (stable/rocky)

Reviewed: https://review.opendev.org/697133
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=34a3ca23b3184e9b356877432d0f44c836705a70
Submitter: Zuul
Branch: stable/rocky

commit 34a3ca23b3184e9b356877432d0f44c836705a70
Author: Gorka Eguileor <email address hidden>
Date: Mon Oct 14 16:42:22 2019 +0200

    Fix FC scan too broad

    After some changes to the FC connector we have introduced a regression
    on the way we do the scans, and we end up scanning using wildcards even
    though we shouldn't.

    The targets in the "initiator_target_map" don't mean that they are all
    connected, so we must take that into account.

    With the current code, if we have the following connections:

    HBA host7 ---- SWITCH ---- port W (channel 0, target 2)
              \--- SWITCH ---- port X (channel 0, target 3)

    HBA host8 ---- SWITCH ---- port Y (channel 0, target 2)
              \--- SWITCH ---- port Z (channel 0, target 3)

    We will end up with the following scans 8 scans for LUN L:

      - - L > host7
      - - L > host7
      0 2 L > host7
      0 3 L > host7

      0 2 L > host8
      0 3 L > host8
      - - L > host8
      - - L > host8

    Which correspond to the responses from _get_hba_channel_scsi_target like
    this:

                   port Y port Z port W port X
      host7 ... ['-','-',L] ['-','-',L] ['0','2',L] ['0','3',L]
      host8 ... ['0','2',L] ['0','3',L] ['-','-',L] ['-','-',L]

    And we should only be doing 4 scans:

      0 2 L > host7
      0 3 L > host7
      0 2 L > host8
      0 3 L > host8

    Most storage arrays get their target ports automatically detected by the
    Linux FC initiator and sysfs gets populated with that information, but
    there are some that don't.

    We'll do a narrow scan using the channel, target, and LUN for the former
    and a wider scan for the latter.

    If all paths to a former type of array were down on the system boot the
    array could look like it's of the latter type and make us bring us
    unwanted volumes into the system by doing a broad scan.

    To prevent this from happening Cinder drivers can use the
    "enable_wildcard_scan" key in the connection information to let us know
    they don't want us to do broad scans even if no target ports are found
    (because they know the cause is there's no connection).

    Close-Bug: #1849504
    Related-Bug: #1765000
    Related-Bug: #1828440
    Change-Id: I5dbefaff43fb902b15117b443fc92f7b6a6ad8c9
    (cherry picked from commit 708733e49598145eb8e898d486723dc3df00a52f)
    (cherry picked from commit c76b6dc514b8e17e1211e4a7465a7e2a635adea3)
    (cherry picked from commit 8933503041529978b9fd816e1788b1b0c343b540)

tags: added: in-stable-rocky
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to os-brick (stable/queens)

Reviewed: https://review.opendev.org/696385
Committed: https://git.openstack.org/cgit/openstack/os-brick/commit/?id=2e46deeaa109f46686171e9af6ea12e94eb9e1f7
Submitter: Zuul
Branch: stable/queens

commit 2e46deeaa109f46686171e9af6ea12e94eb9e1f7
Author: Gorka Eguileor <email address hidden>
Date: Mon Oct 14 16:42:22 2019 +0200

    Fix FC scan too broad

    After some changes to the FC connector we have introduced a regression
    on the way we do the scans, and we end up scanning using wildcards even
    though we shouldn't.

    The targets in the "initiator_target_map" don't mean that they are all
    connected, so we must take that into account.

    With the current code, if we have the following connections:

    HBA host7 ---- SWITCH ---- port W (channel 0, target 2)
              \--- SWITCH ---- port X (channel 0, target 3)

    HBA host8 ---- SWITCH ---- port Y (channel 0, target 2)
              \--- SWITCH ---- port Z (channel 0, target 3)

    We will end up with the following scans 8 scans for LUN L:

      - - L > host7
      - - L > host7
      0 2 L > host7
      0 3 L > host7

      0 2 L > host8
      0 3 L > host8
      - - L > host8
      - - L > host8

    Which correspond to the responses from _get_hba_channel_scsi_target like
    this:

                   port Y port Z port W port X
      host7 ... ['-','-',L] ['-','-',L] ['0','2',L] ['0','3',L]
      host8 ... ['0','2',L] ['0','3',L] ['-','-',L] ['-','-',L]

    And we should only be doing 4 scans:

      0 2 L > host7
      0 3 L > host7
      0 2 L > host8
      0 3 L > host8

    Most storage arrays get their target ports automatically detected by the
    Linux FC initiator and sysfs gets populated with that information, but
    there are some that don't.

    We'll do a narrow scan using the channel, target, and LUN for the former
    and a wider scan for the latter.

    If all paths to a former type of array were down on the system boot the
    array could look like it's of the latter type and make us bring us
    unwanted volumes into the system by doing a broad scan.

    To prevent this from happening Cinder drivers can use the
    "enable_wildcard_scan" key in the connection information to let us know
    they don't want us to do broad scans even if no target ports are found
    (because they know the cause is there's no connection).

    Close-Bug: #1849504
    Related-Bug: #1765000
    Related-Bug: #1828440
    Change-Id: I5dbefaff43fb902b15117b443fc92f7b6a6ad8c9
    (cherry picked from commit 708733e49598145eb8e898d486723dc3df00a52f)
    (cherry picked from commit c76b6dc514b8e17e1211e4a7465a7e2a635adea3)
    (cherry picked from commit 8933503041529978b9fd816e1788b1b0c343b540)

tags: added: in-stable-queens
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.