[kots]: add database to preflight checks

[mrsimonemms]

Description

Add a database check to the KOTS preflight checks. This validates that the given configuration is able to make a connection to a MySQL database called gitpod and that the version is 5.7.x - this version check is considered a warning because it's possible that we get anomalies with the versions

Failed

Pass

Related Issue(s)

Fixes #9931

How to test

Install with KOTS - the version to use is sje-kots-config-check.11 in sje/kots-config-check channel

Now change the config values for database in KOTS:

• in-cluster should always pass for both checks
• external should pass with correct credentials (check that DB's firewall allows connections - can make public with 0.0.0.0/0)
• cloud SQL should pass with correct credentials (ensure firewall is closed)

You can create a support bundle and look in the file explorer for database/database.log to see the database that's output

Release Notes

[kots]: add database to preflight checks

Documentation

[mrsimonemms]

/werft run no-preview publish-to-kots

👍 started the job as gitpod-build-sje-kots-config-check.10
(with .werft/ from main)

[mrsimonemms]

/werft run no-preview publish-to-kots

👍 started the job as gitpod-build-sje-kots-config-check.11
(with .werft/ from main)

[corneliusludmann]

Thanks for adding this check. That is very useful! 🚀

Added a few comments. The question, of whether this will work for air-gap is the most important one. I would expect that is works. However, we need to make sure before we release it.

The other comments can be handled in follow-up issues and are no blockers, in my opinion.

[corneliusludmann]

Small optimization suggestion:

For deploying a preview env, we don't need to build this image. We need this only when we deploy a KOTS release. Building this only when the publish-to-kots werft flag is set would help us to not extend the time to wait for a preview env for every dev.

Note: We can handle this in a follow up PR and create an issue and merge the PR as is.

[mrsimonemms]

Yeah, that would be a good optimisation. Is there an example I can use to follow as I didn't know this was possible?

[corneliusludmann]

I think, in .werft/jobs/build/build-and-publish.ts we need to set the version tag in this file, right?

We could get the version with something like this:

const kotsConfigCheckDatabaseTag = exec(`docker run --rm eu.gcr.io/gitpod-core-dev/build/versions:${jobConfig.version} cat /versions.yaml | yq r - 'components.kots-config-check.database.version'`, { silent: true })
            .stdout.trim();

[mrsimonemms]

I don't think so. My understanding is that this will only be built by Werft if it detects a change - as this is very unlikely to change, this won't be built on each push. I think this is more akin to our .gitpod.yml image

[corneliusludmann]

In .werft/jobs/build/build-and-publish.ts we need to set the version tag in this file. (same as above)

[corneliusludmann]

Random thought: Do we still get enough log data with the silent flag for the support bundle or should we remove this flag?

[mrsimonemms]

Yes. The --silent flag basically removes all the connection information. At this point, we're only interested in the version so we can assign it to the version_query variable. It is therefore correct that we have the --silent flag.

Also, there's actually no way of debugging a preflight check so we are limited to just putting the data in a known format so we can perform regex queries on it.

[mrsimonemms]

/werft run

👍 started the job as gitpod-build-sje-kots-config-check.14
(with .werft/ from main)

[corneliusludmann]

Thanks for the clarifications. Ship it! 🚢 😆

[mrsimonemms]

🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢