search

gitpod-io / gitpod

The developer platform for on-demand cloud development environments to create software faster and more securely.
https://www.gitpod.io
GNU Affero General Public License v3.0
13k stars 1.24k forks source link

Identify meta-instances by name rather DB locality #8271

Open geropl opened 2 years ago

geropl commented 2 years ago

Epic: #7435

Currently have one DB per application cluster, and we're holding a d_b_workspace_cluster table in every DB separately. This works because we're copying the cluster configuration, and in theory adds additional flexibility for configuring traffic flow. The application cluster -> workspace cluster relation is so far maintained implicitly by DB locality.

This obviously breaks if we move to a single DB setup. There are two possible solutions to this:

  1. maintain the theoretical flexibility (and duplication) and introduce an appInstallation column to mark those rows to belong to the respective application cluster
  2. introduce an governedBy column (and later remove the governed flag), which expresses which app cluster governs which ws cluster. This would result in one row per workspace cluster, having all app clusters share the same traffic-shaping config.
geropl commented 2 years ago

After discucssion with @csweichell we went with a variation of 2:

  1. basic changes

    • introduce a new governedBy column: to maintain full rollback capability for webapp
    • on gpl clusters update / register have bridge set governedBy to installationShortname if governedBy is not set: decouples webapp deployment from workspace cluster deployments (which can still use the old contract in their deployments
    • ensure that ClientProvider can handle multiple entries with the same name for workspace-actions (ports, stop, etc.)

  2. merge DBs

    • double-check that the content of d_b_workspace_cluster tables is identical in both DBs (except for govern)
    • change contract of gp clusters update / register to only be executed once, against one cluster only

  3. cleanup

    • remove old govern flag
stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.