fix: one unhealthy drive no longer fails its controller's inventory

[g-carre]

Commits, one per adapter fix: megaraid, ssacli, storcli2 drives, storcli2 volumes.

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 replaces #103 (stacked on the closed YAML PR #102) and 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, Exposed to OS: No) and is no longer a block device. getPaths still tried to resolve its paths, failed, and failed LogicalVolumes for the whole controller.
  • A volume reported Exposed to OS: No now 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.
• 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 test: describe hardware scenarios in Gherkin, play them on the adapters #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. 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, until the volume is exposed or NewVolumeSettleTimeout (60 s, also when left at zero) elapses. As in megaraid, an offline volume with the same drives cannot hide the new one. A volume counts as not exposed only when it has no path at all, so an exposed volume without an NAA Id (device path only) is returned at once.
• 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);
  • 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 volume not exposed to the OS gets no paths, and 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.

Delivery

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

[claude]

This returns on the first volume that shares a drive slot and has no paths, and skips the rest of the list. hasMatchingPDs matches on any one shared slot. So if the offline volume of a failed drive still lists that slot after the drive is replaced, it can show up before the new volume, and CreateLV keeps retrying until it times out even though the new volume is already exposed. Use continue so the loop still checks the other volumes. It still ends in an error, and a retry, when no matching volume has paths.

Suggested change

	return nil, errors.Errorf("new logical volume %s has no device yet", lv.ID)
	continue

[claude]

This also changes storcli2 CreateLV. logicalvolumemanager.StorCLI2.findNewLogicalVolume returns the first volume with a matching drive set, without checking its paths. The PR says a new volume can be listed before it is exposed to the OS. In that case CreateLV now returns the volume with empty DevicePath/PermanentPath, where before it got the NAA-based path. Add the same wait as in megaraid: treat an empty PermanentPath as not settled and retry, or make the creator re-query until the volume is exposed.

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

[claude]

This has the same early-return issue that was fixed in megaraid's selectNewLogicalVolume. If the offline RAID0 volume of a failed drive still lists the replaced slot, it matches the single-drive set exactly. When it is listed before the new volume, this returns errNewVolumeNotExposed without checking the rest of the list, so CreateLV waits 60 s and fails even though the new volume is already exposed. Remember the unexposed match and continue, then return errNewVolumeNotExposed after the loop only if no matching volume has paths.

[claude]

An empty PermanentPath does not only mean "not exposed". The getter also returns it when SCSI NAA Id is empty (see the empty case in TestStorCLI2PermanentPath). In that case an exposed new volume that has a DevicePath is treated as unsettled, so CreateLV waits 60 s and fails after the volume was already created. An unexposed volume has both paths empty, so check both.

Suggested change

	if lv.PermanentPath == "" {
	if lv.PermanentPath == "" && lv.DevicePath == "" {