Help unblock deploys to version.gitlab.com

Related meta topic: ownership of version.gitlab.com

Capturing a thread from @lstahlman, deploys to version.gitlab.com are currently failing due to an old version of KAS.

Reference MR: gitlab-org/gitlab-services/version.gitlab.com!241 (merged)

Slack thread:

Michał Wielich   Oct 27th at 09:15
Hello team!
An error popped up in the deploy jobs of version app : https://gitlab.com/gitlab-org/gitlab-services/version.gitlab.com/-/jobs/11863106774
 No PostgreSQL helm values file found at '.gitlab/auto-deploy-postgres-values.yaml'
A similar problem has been previously solved by Dat Tang , but he's on PTO now. Would someone be able to help? :pray:


Doug Stull
SRE folks(@Igor W @Dat Tang) - any idea why my pipeline is failing on some postgres timeout looking failure on setup in https://gitlab.com/gitlab-org/gitlab-services/version.gitlab.com/-/jobs/11632386936#L525
Thread in version-gitlab-com | Oct 7th | View message
3 replies


DaveSmith   Oct 27th at 11:31
Sorry, we are short on SREs this week.  Based on that thread from last month, I wonder if we ever updated the kas agent?  Looks like it is still 17.8.1.
I wonder if we can upgrade them per https://gitlab.com/gitlab-org/gitlab-services/cluster-management#agents-are-installed-using-helm-and-terraform
@Devin checking with you though not sure you all own these clusters any more.  Would you agree upgrading per the readme is a good / safe step to try for staging?


Devin :house:  Oct 27th at 16:46
This is owned by Runway now - the version app is supposed to be moving to Runway at some point. Updating KAS agent in the current cluster should be safe enough. I'm not sure how behind the other stuff is, so I'd recommend doing the minimum necessary change at first. I have solved that particular error in other places by simply creating an empty file at that location.

DaveSmith  Oct 27th at 16:47
thank`s - I'll take to #g_runway