-
Notifications
You must be signed in to change notification settings - Fork 52
Description
nexus-test-utils
populates its initial blueprint's sleds' datasets and disks based on the zones for that sled. However, these datasets and disks are just made up entirely on the spot, and have no correlation with the disks and datasets each simulated sled-agent will claim to have. This puts clients of this test setup code in an awkward position: they can't assume the blueprint they've been given is valid in the same way that a blueprint produced by the planner or real RSS is (i.e., that datasets/disks are populated in a valid way).
This may be somewhat tricky to untangle, depending on how much fidelity we care about. In real rack setup, RSS asks each sled-agent for its disks, then generates a plan and blueprint assigning zpools to each of those disks and zones/datasets to each of those zpools. In this test-utils path, though, we create a plan and blueprint before starting simulated sled-agents, which themselves then fabricate some number of disks. Ideally the simulated sled-agents would report disks that match the disks and datasets we populate in the test-utils blueprint.
Ideally we could use BlueprintBuilder
here instead of creating a blueprint by hand; that may be hard or impossible given its current API, though.