Avoid ws-manager-mk2 metrics duplication

[aledbf]

Description

Only the leader replica maintains the workspace metrics.

Summary generated by Copilot

🤖 Generated by Copilot at 2e1c129

Improve leader election and workspace reconciler logic in ws-manager-mk2. Delay the reconciler initialization until the leader is elected and run it in a separate goroutine.

Related Issue(s)

Fixes #

How to test

Documentation

Preview status

Gitpod was successfully deployed to your preview environment.

• 🏷️ Name - aledbf-metrics
• 🔗 URL - aledbf-metrics.preview.gitpod-dev.com/workspaces.
• 📚 Documentation - See our internal documentation for information on how to interact with your preview environment.
• 📦 Version - aledbf-metrics-gha.16200
• 🗒️ Logs - GCP Logs Explorer

Build Options

Build

• /werft with-werft
  Run the build with werft instead of GHA
• leeway-no-cache
• /werft no-test
  Run Leeway with --dont-test

Publish

• /werft publish-to-npm
• /werft publish-to-jb-marketplace

Installer

• analytics=segment
• with-dedicated-emulation
• workspace-feature-flags
  Add desired feature flags to the end of the line above, space separated

Preview Environment / Integration Tests

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-large-vm
• /werft with-gce-vm
  If enabled this will create the environment on GCE infra
• with-integration-tests=workspace
  Valid options are all, workspace, webapp, ide, jetbrains, vscode, ssh. If enabled, with-preview and with-large-vm will be enabled.
• with-monitoring

/hold

[easyCZ]

What would be the cost/implication to extend the metrics to include leader=true/false instead of this change? It would allow us to observe the non-master as well as the master, and avoids surprises for future changes.

[aledbf]

What would be the cost/implication to extend the metrics to include leader=true/false instead of this change? It would allow us to observe the non-master as well as the master, and avoids surprises for future changes.

Only the leader process reconciles objects. Not sure that change makes sense.

That said, that will introduce an undesired behavior; the leader will set leader=true, and the N standby replicas leader=false. When a new leader is elected (previously a standby replica), it will contain both leader true and false metrics.

[easyCZ]

hat said, that will introduce an undesired behavior; the leader will set leader=true, and the N standby replicas leader=false. When a new leader is elected (previously a standby replica), it will contain both leader true and false metrics.

Yep, it would contain the metrics again. But dashboards/alerts could use leader=true to extract the relevant ones. I guess the main question I'm asking is whether you may need the non-leader replica metrics, or not.

[aledbf]

Yep, it would contain the metrics again. But dashboards/alerts could use leader=true to extract the relevant ones. I guess the main question I'm asking is whether you may need the non-leader replica metrics, or not.

We already have non-leader replica metrics that make sense for the generic parts (provided by controller-runtime)