You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Add options/arguments to the getter or the validator.
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.
Return typed errors and let the caller handle each validation failure type.
Validate everything always and separate it down the line if the need arises.
The text was updated successfully, but these errors were encountered:
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.
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 callingcustomizations.GetPartitioning()
, but the layout constraints aren't checked. Also, theValidate()
function is called in theNewCustomPartitionTable()
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:
The text was updated successfully, but these errors were encountered: