Closed yuvipanda closed 5 months ago
I'd like this to involve all the folks who have worked on this so far, which is me @consideRatio and @GeorgianaElena. Let's at least do a 1hr session with us three, and then we decide on more split sync sessions as needed. I propose 7AM pacific on Tuesday, May 21. Does that work for you both, @consideRatio and @GeorgianaElena?
@yuvipanda, yes, that works for me. Thank you
@yuvipanda yes that works well!
Great, I've sent an invite.
Notes from today's meeting: https://hackmd.io/G06D9YfOSsSf_mt13EeZoA?both
Next step is for @consideRatio and @GeorgianaElena to have a meeting between themselves to validate these requirements by testing it out locally, trying to set up a connection between binderhub-staging and a jupyterhub. @GeorgianaElena is to drive this, to make sure that @consideRatio doesn't become an engineering bottleneck.
The outcome of that meeting would be to confirm the work needed to connect a binderhub-service instance to a jupyterhub instance next to it, on the same namespace. We have a draft of what we think is needed in the hackmd.
This is code of relevance from the binderhub chart, in how it re-configures the jupyterhub chart: https://github.com/jupyterhub/binderhub/blob/c6c5dc8fe73f81ca538c47b420b33f317c3aa8ae/helm-chart/binderhub/values.yaml#L65-L255
JupyterHub.spawner_class
Needs to be adjusted to reference a class including the BinderSpawnerMixin
.cmd=...
cull
Should jupyterhub users be deleted over time? This isn't of relevance for binderhub-service in either mode I think, but could be of relevance to the truly public hub with nullauthenticator.To enable binderhub-ui we need to also override binderhub-service helm chart defaults:
config.BinderHub.hub_url=false
(was it named like this?)config.BinderHub.binder_badge_url=false
(was it named like this?)config.BinderHub.enable_api_only_mode=false
config.BinderHub.auth_enabled=true
Also https://binderhub.readthedocs.io/en/latest/authentication.html stuff.Me and @GeorgianaElena met and worked for more than five hours to see how far we'd get in deploying something.
I've updated the top comment with a more detailed report of the spike and of the discussions and working session that happened afterwards.
I think with that we can close the spike and track the WIP PR in the new hub issue that Yuvi created https://github.com/2i2c-org/infrastructure/issues/4133. Thank you!
Currently, the binderhub-service chart primarily exposes the binderhub API. Given that we're not going to be using the upstream binderhub chart (https://github.com/2i2c-org/infrastructure/issues/4085), we should explore what is needed for
binderhub-service
to expose the binderhub UI.This should be done keeping in mind that we don't want to tie assumptions about how jupyterhub is deployed into this binderhub. The outcome should be primarily documentation, as well as general extensibility improvements to binderhub-service.
Tasks
Spike outcome
1. Actual spike
@consideRatio, @yuvipanda and @GeorgianaElena met for the spike and after the meeting the following steps were considered that need to happen for a binderhub ui style hub with binderhub-service (this is summarized from https://hackmd.io/G06D9YfOSsSf_mt13EeZoA?both):
2. After-spike conclusion
Have a binderhub architecture walk-though for @GeorgianaElena and other interested 2i2c team members to spread the knowledge
3. After-spike work session
@consideRatio and @GeorgianaElena met after the spike for a working session. @GeorgianaElena's rough plan before the working session was to follow the instructions @yuvipanda wrote for installing and connecting binderhub-service https://binderhub-service.readthedocs.io/en/latest/tutorials/install.html to a hub and from there, go with the plan @yuvipanda and Erik put toghether during the spike (referenced at point 1).
But:
So we concluded to:
We:
We are not done yet, but prototyping this new hub helped identify some missing steps.
Outcome of that session is https://github.com/2i2c-org/infrastructure/pull/4119