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

Disk customization validation #1065

Open
achilleas-k opened this issue Nov 25, 2024 · 1 comment
Open

Disk customization validation #1065

achilleas-k opened this issue Nov 25, 2024 · 1 comment

Comments

@achilleas-k
Copy link
Member

With the new DiskCustomization we have two levels of validation:

  • Validate() checks the structure for inconsistencies, conflicts, and missing values that make the customization invalid.
  • ValidateLayoutConstraints() checks for things that are, strictly speaking, possible but not supported by the library due to our own internal policy (for example, multiple LVM volume groups or btrfs volumes).

This separation is useful for users of the library that may want to validate one but not the other. Currently, Validate() is run automatically when calling customizations.GetPartitioning(), but the layout constraints aren't checked. Also, the Validate() function is called in the NewCustomPartitionTable() function to check for the inconsistencies but doesn't disallow creating a partition table that violates the layout constraints.

There is a concern that this separation might cause issues with validations being dropped because callers might forget or not realise that there are multiple validations to run.

I should also add that there is a third validation, CheckMountpointPolicy(), for checking if custom mountpoints are allowed for a given image type.

We should make it easier to validate customizations, harder to skip a specific validation, but also make it possible when needed.

Proposals:

  1. Add options/arguments to the getter or the validator.
  2. Validate everything in the getter function but also keep validator functions separate, so any caller can, if needed, get the customizations without calling the getter and call each validation separately.
  3. Return typed errors and let the caller handle each validation failure type.
  4. Validate everything always and separate it down the line if the need arises.
@bcl
Copy link
Contributor

bcl commented Nov 26, 2024

I'd add disable options to the validator. This way there's one things to call, and by default it validates everything. And when someone copy and pastes an example they don't have to know about optional other validators :) If users need it to be less strict they can disable the layout and or constraint validation.

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

2 participants