The-turing-way: Value of a Turing-hosted instance of mybinder.org

[sgibson91]

Summary

Is there a value in the Turing hosting another instance (or a copy of ) mybinder.org?

Pros:

• The world needs more BinderHubs
• Showcases Turing open source philosophy

Cons:

• Cost and Maintenance
• Branding/Comms w.r.t. mybinder.org and the team

What needs to be done?

• [ ] Is this a good idea?

Who can help?

---

Updates

[sgibson91]

mybinder.org are looking for sub-domains to redirect traffic to, see jupyterhub/team-compass#144

[sgibson91]

@martintoreilly shall we build a sub-domain of mybinder.org? ☝️

[sgibson91]

Plan is to request 10k of credits to fund a small cluster for a year to join the International Binder Federation.

• subscription should not be allowed to exceed 10k / year
• k8s cluster and ACR should be "simple" enough to set up
• confer with @betatim and @choldgraf about the technical aspects of including our cluster into the federation

[choldgraf]

Check out https://binderhub.readthedocs.io/en/latest/federation/federation.html#joining-the-binderhub-federation

For a bit more information!

[betatim]

On the technical side:

I think the easiest thing to do in terms of keeping admin overhead low would be to deploy the Turing binder from the mybinder.org-deploy repository as well. Pros: always in sync, not much more effort required to deploy, banned repos and so on are automatically shared, direct access to Binder ops team experience. Cons: access keys to the GKE, OVH and Turing accounts would be in one place (increasing the value of breaking into the repo), deploying three instances from one repo makes a deploy more unwieldy, (perceived) less ownership by the Turing team of the deployment.

Having a separate repo would give more exposure to people from the Turing who are managing the deployment. It would also give them more authority as well as responsibility (keeping in sync, analysing outages, tuning performance, fixing outages, etc).

Because the federation redirector is controlled from the mybinder.org-deploy repo I think it would be wise to have someone (in addition to Sarah to avoid single points of failure) from the Turing team join the Binder ops team so they have access and can turn on/off traffic. The redirector will get smarter about detecting "broken" instances but no matter how smart you'd want access to the master tap so you can turn off (and make sure it stays off) the fire-hose when you need to.

Otherwise: Sarah has access so she can create a PR that adds the config and keys needed to start deploying to a Turing instance. We'd probably follow a similar strategy as with the OVH deployment: start deploying but send no traffic, start sending 1 or 2% of traffic, check, fix things, step up traffic, rinse repeat.

[sgibson91]

Turing IT may have something to say about putting deploy keys in someone else's repo as well 🤔

[sgibson91]

This is in progress in https://github.com/jupyterhub/mybinder.org-deploy/issues/1154 and https://github.com/jupyterhub/mybinder.org-deploy/pull/1203 :tada:

[sgibson91]

MERGED!