[sled-agent-config-reconciler] Add separate OmicronDatasets type
#8218
Conversation
This is more consistent with how the reconciler remembers zones and disks. This is almost all just moving code around. The only nontrivial changes are: 1. In the spot where we ought to delete datasets, we at least "forget" them in-memory and log an error about leaking the ZFS dataset 2. The dataset serialization task remembers fewer details about datasets it ensured (just the names - that's all we need for the error checking it does when dealing with nested datasets)
| }; | ||
| self.datasets | ||
| .iter() | ||
| // Fitler down to successfully-ensured datasets |
There was a problem hiding this comment.
| // Fitler down to successfully-ensured datasets | |
| // Filter down to successfully-ensured datasets |
| //! There is no separate tokio task here; our parent reconciler task owns this | ||
| //! set of datasets and is able to mutate it in place during reconciliation. |
There was a problem hiding this comment.
I'm trying to make this comment "There is no separate tokio task here" make sense, given that there is a DatasetTaskHandle field in the OmicronDatasets field below.
Seems like there is both a task-independent dataset structure, as well as a task?
There was a problem hiding this comment.
Mm yeah this is confusing. My intent was "this datastructure isn't one that spawns a task and uses a channel to communicate to it", which is true, but it does need to use the dataset serialization task handle that's spawned elsewhere (and is also used to service support bundle nested dataset operations and inventory collections).
Maybe DatasetSerializationTask should be ZfsSerializationTask - would that be clearer?
This is more consistent with how the reconciler remembers zones and disks. This is almost all just moving code around. The only nontrivial changes are:
Staged on top of #8064. PR 1 of 3 working towards #8173.