Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[reconfigurator] SledEditor: be more strict about decommissioned sleds (
#7234) This is a followup from #7204 (comment) and makes two changes, neither of which should affect behavior: * `SledEditor` will now fail if a caller attempts to make changes to a decommissioned sled (internally, this is statically enforced by a type state enum - a sled in the decommissioned state does not have any methods that support editing, so we're forced to return an error) * `SledEditor::set_state()` is now `SledEditor::decommission()`, and it performs some checks that the sled looks decommissionable The second bullet is more questionable than I expected it to be: 1. There are some arguments that `SledEditor` shouldn't do any checks here; in particular, it doesn't have the full context (e.g., any checks on "should we decommission this sled" that depend on the `PlanningInput` can't be performed here, because `SledEditor` intentionally doesn't have access to `PlanningInput`). 2. I wanted to check zones + disks + datasets, but in practice it can only check zones today; I left a comment (and the commented-out disks + datasets checks we should do) about why. I think we will eventually be able to turn these on; the current behavior of removing disks/datasets from the blueprint for expunged sleds will have to change to fix #7078, at which point these checks should be valid. I don't feel super strongly about the checks in `decommission()` or even this PR as a whole; if this doesn't look like a useful direction, I'd be fine with discarding it. Please review with a pretty critical eye.
- Loading branch information