Skip to content
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

A user (with privileges) should be able to chose a workspace cluster explicitly #4809

Closed
meysholdt opened this issue Jul 14, 2021 · 6 comments
Labels
meta: stale This issue/PR is stale and will be closed soon

Comments

@meysholdt
Copy link
Member

Use cases: If there are multiple pluggable workspace clusters...

  • with admission constraints and you want to choose one
  • or the cluster you want to start a workspace in has a low "score" and you don't want to start 10 workspace to have at least on end up on the right clusters. In fact, some colleagues could not use this strategy in the past because they did not have an "unleashed" plan and ran into the workspace limit too early.

Proposal:

  • support an &cluster=eu12 argument in the context urls, similar to how we do it to trigger prebuilds manually and pass ENV vars.
  • since we only use this for testing this argument should only be usable by people who have the permission to do so, e.g. the new-workspace-cluster permission. We don't want to give users the ability to override our loadbalancing/failover/cluster-cycling strategies.

Context: @geropl brought this up in today's all-hands.

@csweichel
Copy link
Contributor

Other simple solution: extend the admission constraints to explicitly name users, i.e. introduce a user= admission constraint.

Pro: does not require plumbing cluster choice to workspace context/config.
Downside: still not as flexible as passing it in as env var.

or the cluster you want to start a workspace in has a low "score"

This case I don't understand yet. Why can't we just raise the score while testing the cluster?

@csweichel csweichel moved this from Inbox to Scheduled (limit: 25 WIP) in [DEPRECATED] Product Engineering Groundwork Jul 14, 2021
@meysholdt
Copy link
Member Author

Why can't we just raise the score while testing the cluster?

it pins you to single cluster :( Sometimes it's nice to work with multiple ones: First start your "dev" workspace on a "stable" cluster and then start a test workspace on the k3s-cluster, another one on EKS, and another one on GKE just to make the comparison.

With that being said, it feels like even with a ration of 10000:50 I still end up on the "50" cluster 1/4 of the time, so I ended up starting multiple workspace in the past.

Another nice use-case for having the cluster-name in the URL: We can share such URLs in Slack "here, try this cluster".

@csweichel
Copy link
Contributor

With that being said, it feels like even with a ration of 10000:50 I still end up on the "50" cluster 1/4 of the time, so I ended up starting multiple workspace in the past.

That sounds like a separate bug we should look into

Another nice use-case for having the cluster-name in the URL: We can share such URLs in Slack "here, try this cluster".

That's a great use-case indeed

@csweichel
Copy link
Contributor

/schedule

@csweichel
Copy link
Contributor

In conversation with @meysholdt we've decided to skip this feature for now. Removing from groundwork.

@stale
Copy link

stale bot commented Nov 9, 2021

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.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Nov 9, 2021
@stale stale bot closed this as completed Nov 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta: stale This issue/PR is stale and will be closed soon
Projects
None yet
Development

No branches or pull requests

3 participants