[ws-manager] Make cluster selection filter by application cluster #14000
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
October 19, 2022 11:23
Allow filtering by name and applicationCluster.
|
started the job as gitpod-build-af-use-app-cluster-in-ws-manager-api.8 because the annotations in the pull request description changed |
|
started the job as gitpod-build-af-use-app-cluster-in-ws-manager-api.9 because the annotations in the pull request description changed |
12 tasks
sagor999
approved these changes
Oct 20, 2022
easyCZ
reviewed
Oct 20, 2022
|
|
||
| public async getWorkspaceCluster(name: string): Promise<WorkspaceCluster | undefined> { | ||
| return this.clusters.find(m => m.name === name); | ||
| return this.clusters.find((m) => m.name === name && m.applicationCluster === this.applicationCluster); |
There was a problem hiding this comment.
For debugging purposes, I'd recommend logging the following:
- The set of clusters available
- The set of clusters which match this application cluster
We can add these as log fields. This would help us identify scenarios when the filtering logic doesn't work as expected.
There was a problem hiding this comment.
The extra benefit of this is if we accidentally end up in a situation where there is more than 1 cluster that matches, we'd see that in the logs when debugging.
easyCZ
approved these changes
Oct 20, 2022
3 tasks
roboquat
added
deployed: webapp
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Context
As part of #9198 we want to start syncing the `d_b_workspace_cluster` table with `db-sync`.Currently, the table differs between US and EU regions because each table contains only the data relevant to that region. For example, in the EU table, the
eu70workspace cluster is marked asavailableand theus70cluster iscordoned. In the US clustereu70iscordonedandus70isavailable.In order to sync the table we need to get to a point where there is no difference in the data in the table between EU and US regions.
To do that we will introduce a new field in the table called
applicationClusterwhich records the name of the application cluster to which the record belongs. Thus, for each workspace cluster there will be two rows in Gitpod SaaS:Effectively the new
applicationClustercolumn gives the table an extra dimension so that we can combine both tables (EU and US) into one.#13722 added the column to the table and made
gpctlfill the value whengpctl registering a new workspace cluster. The value is taken from theGITPOD_INSTALLATION_SHORTNAMEenvironment variable inws-manager-bridge.Make the cluster selection mechanism in
ws-manager-apiaware of the application cluster to which each workspace cluster is registered. Previously, the selection was by workspace cluster name only. Soon, as described in the context section, each region in gitpod will store records in the database for all workspace clusters - not just the ones in its region. This PR ensures that workspace clusters not in the same regions as the application cluster will not be considered.Related Issue(s)
Part of #9198 and #13800
How to test
Edit the
serverdeployment and change theWSMAN_CFG_MANAGERSenvironment variable to change theapplicationClusterto which the default workspace cluster in the preview environment is registered:[ { "name": "", "url": "dns:///ws-manager:8080", "tls": { "ca": "/ws-manager-client-tls-certs/ca.crt", "crt": "/ws-manager-client-tls-certs/tls.crt", "key": "/ws-manager-client-tls-certs/tls.key" }, "state": "available", "maxScore": 100, "score": 50, "govern": true, "admissionConstraints": null, "applicationCluster": "" // <- change this from "" to anything else } ]The
WSMAN_CFG_MANAGERSenvironment variable is base64 encoded.Once the
serverdeployment is edited it should no longer be possible to start a workspace as the only workspace cluster is now associated with a different (non-existent) application cluster.Edit the
WSMAN_CFG_MANAGERSenvironment variable once more and set theapplicationClusterfield back to"". Starting a workspace should now proceed as normal (the application cluster in preview environments is currently called"").Release Notes
Documentation
Werft options:
If enabled this will build
install/previewValid options are
all,workspace,webapp,ide