Assume that preview envs without mysql-0 are not active.

[meysholdt]

Description

We have may preview envs running without mysql-0 DB. To ensure they get garbage collected eventually, this PR treats them as not active.

Related Issue(s)

Context: https://gitpod.slack.com/archives/C01KGM9EBD4/p1655991725949059

How to test

Release Notes

NONE

Documentation

Werft options:

• /werft with-preview

[mads-hartmann]

LGTM. Would be nice to follow up with https://github.com/gitpod-io/ops/issues/2758 just in case this means we're deleting preview envs prematurely

[ArthurSens]

Do we know if it is common to have db connection issues during this check?

I believe we made this assumption because we were afraid of small connection issues that could delete previews that were actually in use.

If we make sure that we only spin up VMs when a preview is required, wouldn't it solve this problem of trying to connect to a non-existing database?

[meysholdt]

If we make sure that we only spin up VMs when a preview is required, wouldn't it solve this problem of trying to connect to a non-existing database?

I think not, because even then there can be preview envs without gitpod installed. E.g. the install failed or somebody simply deleted Gitpod. Even in those scenarios we need to be 100% sure the VM gets GCed eventually.

Idea: If there is connection trouble, garbage-collect less aggressively. E.g. after 5 days. Or 7 days. maybe somebody is just re-installing Gitpod.