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

Don't link to mybinder.org clusters directly #1

Open
betatim opened this issue Jul 31, 2019 · 4 comments
Open

Don't link to mybinder.org clusters directly #1

betatim opened this issue Jul 31, 2019 · 4 comments

Comments

@betatim
Copy link

betatim commented Jul 31, 2019

Hi 👋 !

nice work with the template! I just wanted to stop by to let you know that we don't want people using the individual instances of mybinder.org directly (gke.mybinder.org and ovh.mybinder.org). The reason for this is that we might rename the instances or take one of them offline without notice for maintenance. If you link to mybinder.org we will redirect users to the best available cluster.

@matheusmota
Copy link
Member

Hi @betatim. Thanks for reaching us out.
I understood your point, it makes sense. We'll be removing direct links.
We have been using this strategy on the badges to avoid reaching a federated instance in which the image is not built already. But ok, loading balancing between the federated instances is certainly better.

Please let us know if there is anything else we could do to help mybinder.
Thanks again and congrats to you and the team for the outstanding job with repo2docker/binderhub/mybinder.

@betatim
Copy link
Author

betatim commented Aug 1, 2019

We are working on smarter routing to each of the clusters and within a cluster. Take a look at jupyterhub/mybinder.org-deploy#1066. Help with that would be super welcome. I think the first step would be a bit of prototyping to figure out what the edge cases are, components/inputs that are need (for example "how busy is cluster A?" seems like a metric we'd need) and then implementing it "for real".

It makes sense to use a hack like linking directly to one cluster to try and avoid rebuilding but it has the downside that if we move the cluster or it is unhealthy the link will be broken. Hopefully improvements to the routing will remove the need for the hack :)

@betatim
Copy link
Author

betatim commented Dec 2, 2019

Hey,

a heads up from our side: we have implemented the load balancing a few weeks ago. This means a particular repo always gets assigned to the same cluster (if that cluster has space).

@matheusmota
Copy link
Member

That is great news, Tim! Thanks for letting us know.

@matheusmota matheusmota reopened this Dec 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants