Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BlueprintZoneConfig: track dataset IDs explicitly #7214

Open
jgallagher opened this issue Dec 6, 2024 · 0 comments
Open

BlueprintZoneConfig: track dataset IDs explicitly #7214

jgallagher opened this issue Dec 6, 2024 · 0 comments
Milestone

Comments

@jgallagher
Copy link
Contributor

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".

@jgallagher jgallagher added this to the 13 milestone Dec 6, 2024
jgallagher added a commit that referenced this issue Dec 6, 2024
Blueprint zones don't contain explicit dataset IDs (yet; see #7214), so
`DatasetsEditor` maintained an internal cache mapping `(zpool, kind) ->
dataset ID`. However, that mapping is only unique for _in service_
datasets, and `DatasetsEditor` was erroneously trying to build it for
_all_ datasets (both in-service and expunged).

This PR adds a few property tests and fixes for the maintenance of this
cache, and should ensure that we only try to maintain the "at most one
dataset of a given kind on a given zpool" map for in-service datasets.
jgallagher added a commit that referenced this issue Dec 9, 2024
)

Blueprint zones don't contain explicit dataset IDs (yet; see #7214), so
`DatasetsEditor` maintained an internal cache mapping `(zpool, kind) ->
dataset ID`. However, that mapping is only unique for _in service_
datasets, and `DatasetsEditor` was erroneously trying to build it for
_all_ datasets (both in-service and expunged).

This PR adds a few property tests and fixes for the maintenance of this
cache, and should ensure that we only try to maintain the "at most one
dataset of a given kind on a given zpool" map for in-service datasets.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant