[g-carre]

Commits, one per adapter fix: megaraid, ssacli, storcli2 drives, storcli2 volumes, then the storcli2 wait for a new volume on the host, with a SCSI rescan.

Fixes ARTESCA-17960 (RD-2154). Stacked on #105: it targets #105's branch, so the diff only shows the fix. Retarget it to main once #105 is merged.It supersedes #91.

Problem

One unhealthy drive could fail the inventory of its whole controller, so every healthy drive on that controller lost its device paths. On the RD-2154 node this blanked all disks in the UI.

Fixes

• megaraid (the RD-2154 case). When the drive of a single-drive RAID0 volume fails, the volume goes offline (OfLn) and is no longer a block device. getPaths still tried to resolve its paths, failed, and failed LogicalVolumes for the whole controller.
  • An offline or failed volume (OfLn, Fail) now gets empty paths without error, whatever its Exposed to OS says. No storcli output was ever captured while a drive was failed (RD-2154 only has the error log), so storcli may still report the volume exposed; with Yes kept, the MegaRAID scenario gives the RD-2154 error again without this check.
  • A volume reported Exposed to OS: No also gets empty paths without error. Only this explicit value (spaces trimmed) skips resolution, since older storcli versions may not report the field.
  • OfLn is now reported Failed instead of Unknown.
• megaraid JBOD drives. A JBOD drive whose by-id link or device node is missing, such as a failed or pulled drive, is kept with empty paths instead of failing the listing of every drive on the controller. Any other failure is still an error. physicaldrive.IsPathMissing holds the rule, and the storcli2 getter uses it too.
• ssacli (from fix: a single failed drive no longer blanks a controller's device paths #91). A failed or pulled drive whose /dev node is gone made the lsblk lookup fail, which aborted the whole inventory. When the device node is gone, a lookup failure now marks the device's usage as unknown instead. Any other lookup failure, such as lsblk missing or failing on a device that exists, is still an error, so it cannot silently blank every drive. A free drive whose usage is unknown is reported Unknown, never UnassignedGood, so a drive that may carry data is never offered for a new volume.
• storcli2 drives (from fix: a single failed drive no longer blanks a controller's device paths #91). A Used JBOD drive whose by-id link or device node is missing is kept with empty paths instead of failing the whole inventory. Any other resolution failure, such as a permission error, is still an error.
• storcli2 volumes. The storcli2 scenario of fix: one unhealthy drive no longer fails its controller's inventory, with hardware scenarios #105 found that the offline volume of a failed drive was still reported with a permanent path built from its NAA Id, although it has no block device. An offline or failed volume, whatever its Exposed to OS says, or a volume reported Exposed to OS: No, now has no paths: neither the permanent path built from its NAA Id, nor a device path from a possibly stale OS drive name.
• Volume creation. It still waits for the new volume: a volume listed before it is exposed to the OS has no paths yet, so it is treated as not settled, and creation keeps rescanning and retrying.
  • megaraid: a volume without paths no longer stops the search, so the offline volume of a failed drive still listing a requested slot cannot hide the new, exposed volume.
  • storcli2: CreateLV used to return a new volume with an NAA-based path even before it was exposed. It now waits, like megaraid and with the same SCSI rescan between checks (on mpi3mr hosts), until the volume is a block device of the host or NewVolumeSettleTimeout (60 s, also when left at zero) elapses. As in megaraid, the volume is settled only once its by-id link (or its device node, when storcli2 reports no NAA Id) exists on the host: storcli2 may report it exposed right after add vd, before the kernel has discovered it. An offline volume with the same drives cannot hide the new one.
• DESIGN.md. Documents the contract that getter read paths degrade gracefully, which failures still are errors, and that the megaraid and storcli2 create paths are deliberately stricter.

#91's change for multi-drive megaraid volumes is not carried over, since ARTESCA does not use them.

Tests

• Scenarios. In megaraid-disk-failure.feature and storcli2-disk-failure.feature, the scenario "A failed drive does not take the paths of the others" now reports its expected table, so both known bug ARTESCA-17960 reports instead: steps are removed. Until they were removed, those steps failed with "the bug looks fixed". All 12 scenarios pass (4 per controller), for example on MegaRAID:

  --- PASS: TestScenarios/All_drives_are_healthy
  --- PASS: TestScenarios/A_failed_drive_does_not_take_the_paths_of_the_others
  --- PASS: TestScenarios/A_replacement_drive_is_reported_as_a_new,_available_drive
  --- PASS: TestScenarios/A_replacement_drive_gets_the_paths_of_its_new_volume
  

• megaraid unit tests, table-driven:
  • getPaths with Exposed to OS set to No (empty paths, no error), Yes, or empty (paths still resolved);
  • volumePaths: an OfLn or Fail volume reported exposed gets empty paths and no error, an Optl or Dgrd one still has its paths resolved;
  • the volume status mapping, including OfLn → Failed;
  • the new volume selection: an offline volume sharing a slot, listed before or after the new volume, does not hide it.
• Volume creation: a new volume first listed as not exposed must be awaited, not returned without paths.
• ssacli: a failing lsblk lookup does not abort the inventory when the device node is gone, and is still an error when it exists. A free drive whose device could not be inspected is reported Unknown.
• storcli2, from fix: a single failed drive no longer blanks a controller's device paths #91: an unresolvable JBOD drive, and a degraded storcli2 RAID volume. New: an offline or failed volume gets no paths even when reported exposed (volumePaths), a volume not exposed to the OS gets none either, and byIDPath (formerly permanentPath) covers Exposed to OS set to No, Yes and missing. CreateLV waits for a volume exposed on the third listing, gives up on one never exposed, is not hidden by an offline volume with the same drives listed first, and returns at once a volume exposed without an NAA Id.

Known risk

The storcli2 CreateLV wait has not run on storcli2 hardware: none is available at the moment. It waits for the new volume's path on the host and rescans the mpi3mr SCSI hosts between checks, as megaraid does, with the same sysfs write. If a new storcli2 volume still does not appear, CreateLV fails after 60 s, and the volume stays on the controller (MK8S-467).

Delivery

disk-management-agent picks this up once raidmgmt is released and the agent bumps it.

[claude]

This drops every getBlockDevice error, not just a missing device node. If lsblk is missing, fails for another reason, or its JSON format changes, every drive silently loses its DevicePath and every free drive becomes Unknown, and nothing reports why. That is the "all disks blanked" symptom this PR fixes, now with no error at all. Only degrade when the node is actually gone (for example, check that value exists before calling lsblk), and keep returning the wrapped error otherwise.

[riadelhajjaji-scality]

You say in DESIGN.md that a JBOD drive whose by-id link can't be resolved is returned with empty paths. That s true for storcli2 (isPathMissing), but the legacy MegaRAID adapter still fails the whole PhysicalDrives() listing at raidcontroller/megaraid/physicaldrive.go:131. Should we apply the same fix for MegaRAID or scope the DESIGN.md sentence to storcli2 and ssacli ?

[g-carre]

Good catch: the legacy MegaRAID adapter had the same problem, and it was worse, since it looks up the paths of every JBOD drive, failed ones included. A failed or pulled JBOD drive would blank every drive of the controller, which is the ARTESCA-17960 symptom. Our scenarios didn't catch it because the captures only have RAID0 volumes.

Fixed in 9673f89 rather than narrowing DESIGN.md, which is now true for all three adapters:

• Shared check. physicaldrive.IsPathMissing(err) sits next to ErrNoPermanentPath. It is true for a missing by-id link, or a link to a device node that is gone. The storcli2 getter uses it in place of its own isPathMissing.
• MegaRAID (megaraid/physicaldrive.go): a JBOD drive whose link or node is missing is kept with empty paths. Any other error, such as a permission error, still fails, as in storcli2.
• Tests:
  • TestPhysicalDriveJBODWithoutLink: a JBOD drive in state JBOD or Failed with no by-id link is returned with empty paths. It fails without the fix ("failed to compute paths").
  • TestIsPathMissing covers the shared check.

The change is in the megaraid commit, and the storcli2 JBOD commit uses the shared check.

[ezekiel-alexrod]

See the above claude review comment

[riadelhajjaji-scality]

LGTM! Just waiting on Claude's comment