support-bundle storage: address lingering TODOs around transition from StorageManger to config reconciler #9224
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 makes two changes; the first is small and does affect prod (but should be very obviously correct), and the second is large but only affects tests:
LocalStorage::dyn_datasets_config_list() -> Result<DatasetsConfig, _>
withLocalStorage::dyn_dataset_config()-> Result<DatasetConfig>
. The former returned an entireDatasetsConfig
, which no longer exists insideOmicronSledConfig
, so the prod implementation of the method had to create one. But the sole caller really only wanted that to look up a single dataset, so replace the method with one that looks up a single dataset.LocalStorage
backed byStorageManagerTestHarness
to being backed bysim::Storage
. This has a couple pros and one con: pros are that we remove a reference toStorageManager
(which is no longer used in prod, but this isn't obvious - ideally we could get rid of all the test consumers and then remove it to avoid confusing) and that the tests can now run on non-illumos systems; con is that we're no longer exercising true ZFS operations in these tests. But I think the point of theLocalStorage
trait is that we don't need to exercise ZFS itself, so this con seems pretty mild to me?Using
sim::Storage
required adding some tracking of a (fake)mounted
property to the "datasets" it keeps track of in memory. I think this is okay? But the nested dataset / dataset split in the APIs is still confusing to me so I could easily have screwed something up in here.