Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 23, 2022
Merged

Conversation

meysholdt
Copy link
Member

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

Copy link
Contributor

@mads-hartmann mads-hartmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@roboquat roboquat merged commit 5407e1a into main Jun 23, 2022
@roboquat roboquat deleted the me/main branch June 23, 2022 14:30
@ArthurSens
Copy link
Contributor

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
Copy link
Member Author

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.

@meysholdt meysholdt mentioned this pull request Jun 23, 2022
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants