Today, BlueprintZoneConfig contains an optional filesystem_zpool:
|
/// zpool used for the zone's (transient) root filesystem |
|
pub filesystem_pool: Option<ZpoolName>, |
and specific zone types that have durable datasets likewise track which zpool their dataset is on. Once R12 is out the door, we'll know that all current target blueprints have fully populated the blueprint_datasets map.
We have a requirement that there is at most one dataset of a given DatasetKind in service on any given Zpool. This allows us to map from a zone's filesystem_pool or durable dataset zpool back to a specific dataset in blueprint_datasets, but it's uncomfortably implicit. We should replace filesystem_zpool with a non-optional filesystem_dataset: DatasetUuid and likewise replace the durable dataset zpool references with DatasetUuids, allowing us to be explicit and not need to map between types by building lookup tables.
This should also enable cleaner checks in blippy (once it exists; #6987). If we were writing blippy today, the most it could say is "for each zone, there is a dataset of the expected kind on the expected zpool". After performing this migration to explicit dataset IDs, it could more cleanly check "for each zone, the exact dataset they expect is present".
Today,
BlueprintZoneConfigcontains an optionalfilesystem_zpool:omicron/nexus/types/src/deployment.rs
Lines 726 to 727 in 9b662ea
and specific zone types that have durable datasets likewise track which zpool their dataset is on. Once R12 is out the door, we'll know that all current target blueprints have fully populated the
blueprint_datasetsmap.We have a requirement that there is at most one dataset of a given
DatasetKindin service on any givenZpool. This allows us to map from a zone'sfilesystem_poolor durable dataset zpool back to a specific dataset inblueprint_datasets, but it's uncomfortably implicit. We should replacefilesystem_zpoolwith a non-optionalfilesystem_dataset: DatasetUuidand likewise replace the durable dataset zpool references withDatasetUuids, allowing us to be explicit and not need to map between types by building lookup tables.This should also enable cleaner checks in blippy (once it exists; #6987). If we were writing blippy today, the most it could say is "for each zone, there is a dataset of the expected kind on the expected zpool". After performing this migration to explicit dataset IDs, it could more cleanly check "for each zone, the exact dataset they expect is present".