Validate the configuration as part of a pre-flight check

[mrsimonemms]

Description

Enable validation of the configuration in KOTS in a preflight check.

This also pushes the result of the installation script to a configmap for users to easily read the logs. The reason for the "push to configmap" is because we cannot output dynamic data in an error message (or, at least, there's no documented example from Replicated). This has been noted on the "limitations of Replicated" page as one of the things to solve in the future.

This also removes the serviceaccount/clusterrolebinding that we define in favour of the KOTS RBAC configuration - this was not available when we first did it. We need this change because we need a serviceaccount BEFORE the application is deployed.

Limitations

This tests every piece of data that is not stored in a secret. Currently, that is just the merging of the custom image pull secrets. Because the preflight checks are run BEFORE anything is deployed, we cannot deploy secrets until AFTER they're deployed - there is a ticket open with Replicated that would solve this limitation, although there has been little traction on this as yet.

Theoretically, we could store the config values in plain text in the config map, but this would make them visible in the KOTS dashboard so I have elected to not do this. I'm happy to have discussions on this however.

The refactoring work has reduced this gap from pretty-much everything to a very specific limitation.

Related Issue(s)

Fixes #12015

How to test

1. Deploy your application
2. Set your configuration
3. Start the preflight checks
4. Check that it's valid/invalid as per your test
5. Get the config map (kubectl get configmaps -n gitpod gitpod-installation-status -o jsonpath="{.data.gitpod-installer\.log}") and check the logs are "correct" as per your test

Adding a config patch as the following is a good way of enforcing a failure

domain: ""

Release Notes

Validate the configuration as part of a pre-flight check

Documentation

Werft options:

• /werft with-preview
• /werft with-integration-tests=all
  Valid options are all, workspace, webapp, ide

[mrsimonemms]

/hold

[Pothulapati]

Code looks good, and it works well as expected!

Tried setting observability.logLevel to a random value

this may overwrite all settings: observability:\n  logLevel: random\n"
time="2022-09-22T08:35:52Z" level=info msg="File written to /tmp/gitpod-config.yaml"
Gitpod: Validate config
{
  "valid": false,
  "fatal": [
    "Field 'Config.Observability.LogLevel' failed log_level validation"
  ]
}
Error: configuration invalid
Usage:

And, Fixing it made the tests pass!

Really excited for all the useful validation checks to show up in kots now! 🚀

[mrsimonemms]

/unhold