Repository navigation
Conversation
g-carre
changed the base branch from
main
to
test/ARTESCA-17960-megaraid-disk-failure-scenario
October 12, 2026 09:50
g-carre
changed the base branch from
test/ARTESCA-17960-megaraid-disk-failure-scenario
to
main
October 12, 2026 09:51
Add github.com/scality/raidmgmt/scenario, a separate module so that consumers can play the scenarios without changing the raidmgmt version they test: - features/*.feature: Gherkin scenarios tagged with their controller family. The Background names the capture of a real controller; each scenario plays events on its drives (a drive fails, is replaced, gets a new volume), the ones it depends on written as Given steps, and gives the table of disks expected. When a bug makes it differ today, a known bug step gives the table reported because of it. - scenario: the step definitions, run by godog strictly (undefined steps fail, empty tables and duplicate slots are rejected), and the comparison of what is reported with a table. A known bug passes only while its table is reported; it fails once the expected table is (the bug is fixed) and when neither is (the behaviour changed). A drive reported twice is a difference. Run plays the features of a controller family through a player; Report collects the disks an adapter reports, listing the controllers first as disk-management-agent does. - steps_internal_test.go: checks on the features of testdata/ that the steps fail when they should, for the right reason. - megaraidsim: answers storcli64 commands from a capture with events applied as storcli showed them on RD-2154, and shows the /dev/disk/by-id links of exposed volumes. Drive groups are written as storcli prints them: a number, or "-" for an unconfigured drive. - megaraidsim/adapter_test.go: plays every @MegaRAID scenario through the megaraid adapter of this repository. The first feature, megaraid-disk-failure, replays real storcli output of a lab node, kept to its first 4 single-drive RAID0 volumes and with fake serials and WWNs: all drives healthy, then drive 251:3 failing, being replaced and getting a new volume. The failure scenario documents ARTESCA-17960: the offline volume of the failed drive makes LogicalVolumes fail for the whole controller, so no drive gets a path. CI and the release gate now test and lint every module. Refs: ARTESCA-17960
Add storcli2sim, the backend of storcli2/perccli2 controllers: it answers the commands of the raidmgmt storcli2 adapter (controller listing, drives and volumes) from a capture with events applied. storcli2 reports a drive status apart from its state: a failed drive keeps state Conf with status Failed, a replacement drive is UConf with status Good. Drive groups are written as numbers, or "-" for an unconfigured drive. The capture is the storcli2 test data of this repository, kept to 4 RAID0 drives, with fake serials, WWNs, SAS addresses, volume and controller identifiers. The storcli2-disk-failure feature plays the megaraid-disk-failure scenarios with the same steps. The healthy drives keep their paths when 306:2 fails, but the offline volume of the failed drive is still reported with a permanent path built from its NAA Id, although it has no block device: documented as a known bug of ARTESCA-17960. Refs: ARTESCA-17960
…ntrollers Add ssaclisim, the backend of ssacli controllers: it answers the commands of the raidmgmt ssacli getters (controller listing, physical and logical drive details, show config) from a capture with events applied. ssacli prints text, so the backend edits the lines of the captured sections: drive and logical drive status, serials, disk names, and moves a replacement drive to the Unassigned section once its array is gone. The capture is the ssacli test data of this repository, kept to 4 single-drive RAID0 arrays, with fake serials, WWIDs and identifiers. The ssacli-disk-failure feature plays the megaraid-disk-failure scenarios with the same steps. The ssacli getters already report them as expected: the healthy drives keep their paths, the failed one is Failed, and the replacement drive is UnassignedGood. Refs: ARTESCA-17960
g-carre
force-pushed
the
test/ARTESCA-17960-disk-failure-scenario-gherkin
branch
from
October 12, 2026 14:09
92d09e9 to
74a8271
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Gherkin counterpart of #102, to compare both formats. It follows the conventions of the org's Gherkin suites (metalk8s, artesca, Zenko, scality-tui). There is one commit per adapter: MegaRAID (with the framework), storcli2, then ssacli. It uses the same captures and expects the same tables as #102.
scenarios/*.yaml,controller:keyfeatures/*.feature,@megaraid/@storcli2/@ssaclitag, capture inBackgroundScenarioper phase (its prerequisites asGivensteps), each a subtestchanges:in each controller's vocabularydrive X fails,is replaced by…,a volume is created on…); each simulator applies them the way its controller shows themknownBug: {ticket, reported}But known bug ARTESCA-17960 reports instead:table, right after theThenNew(s *Scenario, phase int)New(capture string, events ...scenario.Event)scenario_test.go(Go API)steps_internal_test.goontestdata/*.featurefixtures: checks each failure case fails, and for the right reasonBehaviour is the same:
Trade-offs:
changes.go.modusesgithub.com/cucumber/godogv0.16.0 instead ofgopkg.in/yaml.v3.scenario.Runtakes a*testing.T, so it can't run inside the agent's Ginkgo envtest suite as is.Not meant to merge alongside #102: keep one of the two.
Refs: ARTESCA-17960