-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[db] Add applicationCluster
field to d_b_workspace_cluster
table
#13722
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
Conversation
@andrew-farries Would like to better understand the resulting semantics of this. It feels wrong to have the resulting rows in the table with the source cluster |
components/gitpod-db/src/typeorm/entity/db-workspace-cluster.ts
Outdated
Show resolved
Hide resolved
@easyCZ You can imagine this to be a directed graph, where we want this table to contain all edges from application to workspace clusters. And each edge contains all parameters to configure the behavior of how the respective application cluster with the workspace cluster. Does that make more sense? |
components/gitpod-db/src/typeorm/migration/1665071320428-AddColumnToWorkspaceClusterTable.ts
Outdated
Show resolved
Hide resolved
started the job as gitpod-build-af-add-column-to-workspace-cluster-table.3 because the annotations in the pull request description changed |
started the job as gitpod-build-af-add-column-to-workspace-cluster-table.4 because the annotations in the pull request description changed |
@andrew-farries It would be nice if |
When reviewing I noticed a mismatch between This:
@andrew-farries We should definitely investigate before the next Self-Hosted realease. 💯 |
started the job as gitpod-build-af-add-column-to-workspace-cluster-table.5 because the annotations in the pull request description changed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @andrew-farries , the change LGTM!
/hold mainly for this nit, please decide whether you want to address or not
551b555
to
b668b3e
Compare
Good point - will address this in a follow up PR. |
b668b3e
to
5025e12
Compare
This is interesting. Looking at the installer code, they are both set to
and
|
What will happen to existing clusters after migration? I assume they will have an empty field for application cluster? Will this break anything? Also, how does traffic routing happens with regards to this table? Does it have any affect on it? For example, in US, eu clusters are cordoned, so that no traffic from US gets sent to EU. (at least that is how I understand it). Want to make sure this change will not break anything anywhere else? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving since I am only an owner of one file, so do not want to block this PR.
Would love to receive response to the questions above as a sanity check.
@sagor999 In short: nothing, as a first step. As mentioned in the description, this PR is only about adding said field, without reading it anywhere.
The next step is to check that it's filled correctly (with |
@andrew-farries Maybe our preview env config code is broken/bad? 🤔 |
The reason for this mismatch will be addressed by 9773389. |
8512929
to
66edaf1
Compare
This field will record to which workspace cluster the information in each row belongs.
Set the application cluster when registering a new workspace cluster. The applicationCluster is set to the value of the GITPOD_INSTALLATION_SHORTNAME env var which must be set in the environment of ws manager bridge.
66edaf1
to
80f626a
Compare
We don't have the shortName value in workspace clusters (yet). That is being added here Just to confirm, will this not break anything if we don't have such value now? |
We only need an installation name to be present in application clusters (specifically, accessible to I don't think the shortname of the workspace cluster is relevant to this PR. |
Description
As part of #9198 we want to start syncing the
d_b_workspace_cluster
table withdb-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
eu70
workspace cluster is marked asavailable
and theus70
cluster iscordoned
. In the US clustereu70
iscordoned
andus70
isavailable
.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
applicationCluster
which 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
applicationCluster
column gives the table an extra dimension so that we can combine both tables (EU and US) into one.As a first step towards this, this PR adds the column to the table and makes
gpctl
fill the value whengpctl register
ing a new workspace cluster. The value is taken from theGITPOD_INSTALLATION_SHORTNAME
environment variable inws-manager-bridge
.Related Issue(s)
Part of #9198
How to test
I'd like to be able to register a workspace cluster from a preview environment to check that the value of
applicationCluster
is correctly populated.Release Notes
Documentation
Werft options:
If enabled this will build
install/preview
Valid options are
all
,workspace
,webapp
,ide