[kots]: add an installation status pod #9455
Conversation
mrsimonemms
force-pushed
the
sje/kots-install-checker
branch
from
e16947e to
e664ad0
Compare
|
/werft run no-preview publish-to-kots 👍 started the job as gitpod-build-sje-kots-install-checker.2 |
mrsimonemms
force-pushed
the
sje/kots-install-checker
branch
2 times, most recently
from
0bf712d to
917f5d7
Compare
|
/werft run no-preview publish-to-kots 👍 started the job as gitpod-build-sje-kots-install-checker.5 |
mrsimonemms
force-pushed
the
sje/kots-install-checker
branch
from
917f5d7 to
3c3531c
Compare
|
/werft run no-preview publish-to-kots 👍 started the job as gitpod-build-sje-kots-install-checker.7 |
mrsimonemms
force-pushed
the
sje/kots-install-checker
branch
2 times, most recently
from
060f2fb to
4f603cf
Compare
|
/werft run no-preview publish-to-kots 👍 started the job as gitpod-build-sje-kots-install-checker.10 |
This uses the Helm status to find out the status of the Helm installation and crashes if it is not "deployed"
mrsimonemms
force-pushed
the
sje/kots-install-checker
branch
from
4f603cf to
9a33625
Compare
github-actions
bot
added
the
team: delivery
mrsimonemms
changed the title
| if [ "$(helm status -n {{repl Namespace }} gitpod -o json | jq '.info.status == "deployed"')" != "true" ]; | ||
| then | ||
| echo "Gitpod: Installation not complete" | ||
| exit 1 |
There was a problem hiding this comment.
Question: (I haven't tested this yet) when an upgrade is happening wouldn't a new deployment be created of the installation-status deployment too? wouldn't KOTS UI show its status as Ready referring from the old deployment?
There was a problem hiding this comment.
Theoretically yes, but only for 10 seconds whilst the sleep waits for the next try. I think that's an acceptable compromise.
In practice, I've not found that to be the case though
| @@ -111,6 +111,7 @@ function publishKots(werft: Werft, jobConfig: JobConfig) { | |||
|
|
|||
| // Set the tag to the current version | |||
| exec(`yq w -i ${REPLICATED_YAML_DIR}/gitpod-installer-job.yaml ${INSTALLER_JOB_IMAGE} ${image}:${jobConfig.version}`, { slice: phases.PUBLISH_KOTS }); | |||
| exec(`yq w -i ${REPLICATED_YAML_DIR}/gitpod-installation-status.yaml ${INSTALLER_JOB_IMAGE} ${image}:${jobConfig.version}`, { slice: phases.PUBLISH_KOTS }); | |||
There was a problem hiding this comment.
Will replace with a job in the KOTS Makefile in separate PR
Description
Under normal circumstances, a KOTS application is able to manage the status of a deployment - presumably through checking an annotation exists on a pod. As we are using the Installer rather than Kustomize/Helm and we cannot add the required annotations, the status will simply check that the resource exists which means that upgrades will find the old resource rather than the new, falsely reporting that the application is deployed.
This uses the Helm status to find out the status of the Helm installation and crashes if it is not "deployed". This gives a KOTS user feedback as to the status of the Gitpod installation job. Unfortunately, it's a little bit brute-force so it show "unavailable" rather than "upgrading", but we're limited by what KOTS provides us.
When the Helm deployment has been successfully completed, it deletes the pod. This is important as the Kubernetes job works on an exponential back-off time - if the installation takes a while, this can result in many minutes until it's marked as "deployed". This makes the feedback as fast as possible.
This is the first of various tasks to make KOTS a more reliable and enjoyable experience, especially when not following the Happy Path.
Related Issue(s)
Fixes #9195
How to test
Deploy via KOTS and check the status
Release Notes
Documentation