Sub domain allocation plan

[betatim]

This PR makes a start on capturing the ideas from #144 and writing them down in our documentation.

I tried to formulate them as "you should do this" instead of rules or negatives.

What do you think?

[choldgraf]

The only thing I'd add is something to describe what happens if any of those conditions are not met (e.g. "The mybinder.org team reserves the right to remove any sub-domains (or redirect them to mybinder.org) in the event that the BinderHub deployment behind a sub-domain is not following these guidelines to an acceptable level" or something like that. What do you think?

[betatim]

Not sure. For me it is implied that if you "fall out of compliance and fail to rectify the situation" you are out. If we start spelling out the rules too much do we encourage rule lawyering? I think that is what I'd worry about. Leaving it somewhat vague/not read like a legal text makes me hope that people will read this in the spirit it is intended and not with a thought towards "how can we exploit the rules".

In the end we control mybinder.org so we can do as we please, the worst outcome is that someone is annoyed that we redirected blah.mybinder.org back to mybinder.org. If they are the kind of person to get annoyed at that they'll probably get annoyed even if there are rules because they'll argue they were following them and ... 🤷‍♂️

If you propose a concrete sentence I'll definitely add it, otherwise I'll wait and see if someone else has an opinion either way.

[minrk]

Something like:

If the BinderHub stops being functional, or is deemed to not behave in an acceptable way, the subdomain may be reclaimed at any time, redirecting back to the root mybinder.org.

[betatim]

Added Min's sentence.

[arnim]

The BinderHub should maintain the look and feel of a stock BinderHub"

Would we (or Pangeo) satisfy this condition?

[betatim]

Would we (or Pangeo) satisfy this condition?

The short answer is: I don't know.

I think we should (edit and then) merge or reject this, then field applications and discuss those in a separate thread.

My feeling is that we will encounter lots of things we didn't think of when we try to use this process. Instead of trying to cover them all up front I'd be Ok with waiting till we encounter them and then amend this document (when needed).

(For example I just wondered what should happen if a hub is at xxx.mybinder.org and users generate binder badges on it. Should they point to xxx.mybinder.org or mybinder.org? What about hubs hosted at a URL prefix that isn't just /?)

[arnim]

what should happen if a hub is at xxx.mybinder.org and users generate binder badges on it. Should they point to xxx.mybinder.org or mybinder.org?

@betatim I would like if we all would just use mybinder.org . This would not only help to prevent fracturing of the ecosystem but also enable things like load balancing (e.g. depending on the usage/health of the different instances) in the future.
However, for that to be possible I think it would be necessary for the new instances (sub domain users) not to be easily banned. If an institution wants to build its service offering (or part of it) around reproducible research with a binder, having an outside entity that has a kill switch would potentially make it difficult for these institutions to invest in the system.

However, I don't have a simple answer there either.

[choldgraf]

Two thoughts:

1. I agree with @betatim that this PR in particular is nearly ready to go. I think we should keep an eye on how things go and plan to revisit this language sometime in the future when we have more experience.

2. I agree with @arnim that we should keep binder links attached to the parent URL as much as possible. I remember @Carreau had a POC implementation to re-direct based on cookies, maybe something like that can be used (e.g. you have a "preferred binder" list)

[choldgraf]

btw ping @SylvainCorlay who asked about this yesterday

[betatim]

This would not only help to prevent fracturing of the ecosystem but also enable things like load balancing (e.g. depending on the usage/health of the different instances) in the future.
However, for that to be possible I think it would be necessary for the new instances (sub domain users) not to be easily banned.

Nods. I think having one set of badge URLs would be good or at least have them so that even when the hub stops existing they don't "rot".

Can you explain a bit how it makes it harder in your scenario if there is some external place that has the ultimate control on how much traffic gets sent from the central "distributer"?

In my mind this only works if we can establish trust amongst those in the rotation. This means we can set the rules together and also formulate them so that it makes it easier to obtain buy in from the bosses and funders (with obvious constraints from an operational side and wanting to provide a high quality service).

---

You could imagine that users set a cookie that says "no matter what send me to hub X" (similar to what Matthias proposed and what https://bndr.it does).

---

My thinking on load balancing go in the direction of trying to automate it as much as possible. Including checking for versions on the hubs in the rotation as part of the health check (that is the motivation for jupyterhub/binderhub#821).

[arnim]

@betatim I see it pretty much the same way. In the end it will depend on whether we can communicate it to the funders and there is certainly (at least for us) a lot to learn.

On the technical side, a student of us is currently experimenting with something similar to bndr.it for our gallery to also allow mybinder or pangeo to be used.

[betatim]

I added a sentence as suggested by @lheagy. Time to merge?