Overview of future work

[consideRatio]

Current status

We have a binderhub-service chart that deploys BinderHub with the feature developed in jupyterhub/binderhub#1647 by @GeorgianaElena that enables BinderHub to be installed and used without a JupyterHub, but possibly also with/from a JupyterHub with some form of integration.

Chart development

• Make providing container registry credentials easy via the helm chart #24
• ci: improve our tests to also trigger a build and push to a registry #26

BinderHub Software development

• Allow building the image without needing to launch it jupyterhub/binderhub#1647
• Contribute to regular maintenance needs
  • Release planning for 1.0.0 jupyterhub/binderhub#1667
  • ci: test failures in main - hub launched pods pending - related to k3s 1.27? jupyterhub/binderhub#1681

JupyterHub integrations development

We know we want to enable users to launch into images they build, and also to develop something that we believe can be reliably sustained as an open source project.

Yuvi has a vision on how to now use binderhub-service from a JupyterHub and is prototyping towards it. By doing this, Yuvi helps us explore and reason about many things at the same time. Among other things, it helps us explore:

• how an integration between jupyterhub and binderhub-service could be from a user perspective
• how an integration can work technically
• how that technically can fit into a broader open source ecosystem and be maintained long term

[yuvipanda]

I've been working on the question of how to build UI here that is sustainable, learning from the lessons of binderhub's current UI. I want the UI to fit into kubespawner without coupling kubespawner to binderhub, or requiring admins to constantly run around copy pasting files into their config for HTML customization.

To that end, I've worked on jupyterhub/kubespawner#724 to make it possible for kubespawner profile_list templates to be more complex and pluggable without requiring too many changes in kubespawner itself. Once that is merged, we can use arbitrary jinja2 templates to implement UI here. As a nice side effect, the current default template is also split up and made more maintainable. I expect that PR to be merged soon.

To figure out how we can 'plug in' to this UI, I've made https://github.com/yuvipanda/prototype-kubespawner-dynamic-building-ui. Note that this is a prototype focused on answering some very specific technical questions around how to build dynamic, complex UI in a sustainable way. I have documented the questions and current answers on the README. This will also help drive possible required changes to upstream kubespawner.

There is a screenshot of how this looks now on that README too for your perusal :) Note that we aren't working on the UX quite yet - the goal is to make sure we are building something that can take sustained frontend work, without repeating the issues of the binderhub frontend. Once the frontend setup is in a stable place, we can then experiment with both the UX!

Excited to be working on this :)