2i2c-org / binderhub-service

https://2i2c.org/binderhub-service/
BSD 3-Clause "New" or "Revised" License
6 stars 3 forks source link

Overview of future work #27

Open consideRatio opened 1 year ago

consideRatio commented 1 year ago

Current status

We have a binderhub-service chart that deploys BinderHub with the feature developed in https://github.com/jupyterhub/binderhub/pull/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

BinderHub Software development

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:

yuvipanda commented 1 year ago

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 https://github.com/jupyterhub/kubespawner/pull/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 :)