Make the remaining bash script part of the installer image instead of the KOTS job template.

[mrsimonemms]

Motivation

The installation script of the installer job in KOTS is currently a bash script defined in the K8s job template YAML file. That's hard to maintain, hard to test, makes it rather cumbersome to write that script, and prevents re-using stuff from this script (e.g. for implementing a preflight check that checks the KOTS config. For that reason, the functionality of the bash script should be part of the installer image instead. That allows re-using it in preflight checks and gives this functionality a proper home. Where appropriate, functions should be moved to the Gitpod installer binary and simply called from the bash script.

Objectives

• Improve maintainability. Maintaining a bash script as part of a YAML file is rather cumbersome.
• Moving parts of the functionality to the installer brings type safety and allows better code testing.
• Allow re-using functions.
• Break the functionality into parts so that they can be tested separately. (Currently, the bash script can hardly be tested.)

Tasks

• move the bash script from installer-job to Installer container image #12197
• Move the installation-status script into the Installer #12259
• Create a config command #12678
• Create a config cluster shiftfs and config files containerd command in the Installer that will do the detection of shiftfs support/containerd location #12198
• create a config build-from-envvars command in the Installer that will build the config.yaml from envvars #12199
• Wire up the code changes in KOTS #12984
• Update the SaaS deployment process to use the refactored config commands #12847
• Validate gitpod config patch, rendered gitpod installer YAML in preflight checks #12015
• Add validation check to ensure that, if limiting user registrations, there is at least one exception #13114
• Refactor the installer envvars #13151

[csweichel]

Is there a way we could make the shell script go away entirely, and instead make it part of the installer (without incurring a hard KOTS dependency)?

Motivation:

• Go is often easier to maintain than bash
• This might be a path how we can empower the other teams to understand the installation process completely again
• We might learn things that could come in handy should we need to move to away from KOTS

[mrsimonemms]

@csweichel yeah, that's basically the intention

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.