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

Generalise and clean up blueprint customization validation for image types #1216

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

achilleas-k
Copy link
Member

Year-old branch that I never finished. I remembered it today during a discussion with @supakeen, @mvo5, and @schuellerf. Opening as draft because I don't want it to disappear or forget about it again.

Add two new methods to the ImageType interface:
- SupportedCustomizations(): Returns a list of strings that indicate
  customizations supported by an image type.
- RequiredCustomizations(): Returns a list of strings that indicate the
  customizations required by an image type.
Add a reverse path field to the CustomizationError that encodes the
path to the customization that caused an error.

The path is constructed in reverse (bottom-up) for convenience when
iterating or recursing through the blueprint structure and is reversed
to top-down when printing the error message.

This will be used to inform the user of the specific key that was added
to a blueprint but wasn't supported (or required and not set) without
any confusion arising from keys that share a name (e.g. kernel.name and
user.name).
A validation function that takes a list of supported paths to keys and a
blueprint and checks that every value set in the blueprint is in the
list of supported options.  This validator is similar to the existing
Customizations.CheckAllowed() function but it doesn't only check for
values on one level - it can check for supported values of arbitrary
depth.  For example, the following value:

    Customizations.Kernel.Name

means that the Name field of the Kernel customization is supported and
if no other item is listed, it also implies that the Kernel.Append
customization is not supported.

This also works with array types, meaning:

    Customizations.User.Name
    Customizations.User.SSHKey

means that the Name and SSHKey options are supported for the User array,
but none of the other fields are supported.

Error messages use the new CustomizationError type to print the path to
the specific option that caused the error.
A validation function that takes a list of required paths to keys and a
blueprint and checks that every value defined in the required list is
set in the blueprint.  This validator operates in a reverse manner than
the validateSupportedConfig() function since it needs to iterate over
the list of required keys and check that they are set rather than
iterate over the keys that are set and check that they are supported.

The format of the required options is the same as for supported.  For
example, the following value:

    Customizations.User.Name

means that the Name field of the each User defined in the Customizations
should be set to a non-empty value.

Non-empty (non-zero) values are only checked for certain types:

    Struct, Pointer, Slice, and String

Other types (Int, Bool, etc) can have valid user-specified zero values.
Test specific error messages when testing failure states.
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

Successfully merging this pull request may close these issues.

1 participant