WIP: Expunge and Decommission disks in planner #7286
Draft
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.
This PR is intended to fix #6999 and #7098.
The executor steps are all independent already except those that will be fixed in this PR. A disk disposition was added to the blueprint and gets changed from
InService
toExpunged
when thePlanningInput
changes. A disk state was also added that goes fromActive
->Decommissioned
. This disk state changes when the parent sled is expunged or the sled-agent has been guaranteed to have seen the disk expungement as reported via inventory.This code fully implements the planner bits. The exucutor bits are going to be pulled in from the fewer-fatal-errors-in-executor-branch. The executor bits are going to be expanded to implement the expunge and decommission as dictated by the blueprint. Because the planner changes are tightly coupled with the executor, they will all come in this PR.
Further code will also be added to represent the disk disposition and state in the blueprint and diff tables for omdb output. This PR is primarily blocked on revamping the diff system. This is particularly necessary because we need to change those tables and update tests and want to do it rigorously after we have a visitor based mechanism for doing so.
There is some more cleanup to do here as well, in particular around the
physical_disk_filter
and things that may not be needed when the executor bits get fully implemented.