search

2i2c-org / binderhub-service

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

UI for building the environments #78

Open jtpio opened 8 months ago

jtpio commented 8 months ago

Context

Thanks for putting this repo together!

Just stumbled on the related blog post today, which seems to be announcing the project a bit more officially: https://2i2c.org/blog/2024/jupyterhub-binderhub-gesis/

The blog post mentions the following sentence:

A pre-selected list of environments (container images), provided by the administrators who set up this JupyterHub

Which leads to the following question: is there also a UI that administrators can use to pre-build these environments? Or are there plans to make one?

A while ago I opened this topic on Discourse to ask this question, which led to this binderhub-service repo on GitHub: https://discourse.jupyter.org/t/ui-for-building-ztjh-ready-images-with-repo2docker-binderhub/22610.

The reason I'm asking is because we have recently been looking updating the existing tljh-repo2docker plugin to make it more modular, and also work with ZTJH deployments. And initiated some work to revamp the UI for building environments (the UI is only available to JupyterHub administrators).

In the end, it looks like both binderhub-service and tljh-repo2docker may have quite a bit of overlap.

So this issue is mostly to get an idea whether the maintainers of this binderhub-service repo would be interested in having a UI to pre-build images (even as opt-in), and potentially join efforts.

Proposal

At QuantStack we currently have some funding to:

  1. Work on revamping the tljh-repo2docker UI with a modern stack, and so the plugin can be installed as a JupyterHub service instead of the current use of c.JupyterHub.extra_handlers:
  2. Make tljh-repo2docker work with both TLJH and ZTJH
    • Which is why switching to JupyterHub service could make sense, so the functionality could be available in more JupyterHub scenarios and not just TLJH
    • It also sounds like tljh-repo2docker may in fact be able to reuse the binderhub package directly for building the images. Building on the recent API mode addition: https://github.com/jupyterhub/binderhub/pull/1647

Updates and actions

Maybe a first step could be to check if tljh-repo2docker could be converted to use binderhub for its backend (or the same stack as used here in binderhub-service). And make it possible to install the UI separately easily, so it could still be used in TLJH but also now in ZTJH with binderhub-service.

Maybe this could be structured in a way it can be useful to multiple deployment scenarios (local hub, TLJH, ZTJH).

Let us know what you think, and if there might be some challenges for providing such UI. Thanks!

jtpio commented 8 months ago

cc @trungleduc @atrawog @SylvainCorlay who may be interested in this discussion

damianavila commented 8 months ago

Pinging @yuvipanda, @consideRatio, and @GeorgianaElena who may be interested in this discussion, @jtpio 😉

yuvipanda commented 7 months ago

Sorry this got lost in github.

This is super exciting, @jtpio! As you know I'm a huge fan of tljh-repo2docker. We explored basing off that to begin with, but instead choose to go the binderhub route. I think expanding the UI that tljh-repo2docker has to work on z2jh has well would be excellent and extremely valuble to a lot of communities! binderhub can work without kubernetes (https://github.com/jupyterhub/binderhub/tree/main/testing/local-binder-local-hub for example), so it can work well with tljh too. There's also now a published binderhub API client.

I'd love to find ways to collaborate with Quanstack and you on this.

What do you think would be a useful next step? A sync meeting to explore options?

choldgraf commented 7 months ago

Just noting that this is something the Binder community has discussed a few times and generally there's been a lot of enthusiasm for this. The last time I can remember, we discussed it in these issues:

I think I even had a little ipywidgets demo of this back in the day

In particular I think that CodeOcean (linked in the issue) has roughly the workflow that I had in mind. They also use JupyterLab components (though I believe their system is all proprietary), so may be good to look towards for inspiration.

yuvipanda commented 7 months ago

I think this is actually quite different from the linked to repo2docker / binderhub issues, as that's about managing the source of the environment itself, while this is more about managing built environments. I think the original announcement of tljh-repo2docker (https://discourse.jupyter.org/t/a-tljh-plugin-to-build-user-environments-with-repo2docker/4258) has screenshots illustrating this quite nicely.

choldgraf commented 7 months ago

Oops - disregard my comment in that case, I must have misunderstood it. Was just trying to provide some helpful breadcrumbs 🙂

Though I'd still check out the code ocean UI workflow because it includes a kind of end to end workflow for defining, building, and selecting environments

jtpio commented 7 months ago

Thanks for the replies!

What do you think would be a useful next step? A sync meeting to explore options?

Yeah I was thinking about joining one of the upcoming JupyterHub meetings to discuss this, but the next one may be challenging time-wise. So we could indeed have a sync-meetings to discuss ideas, and then report here or in different issues?

Would next week for you? For example Monday 19 February? I guess 8-9 am Pacific time would work best?

I looked a bit more into binderhub-service and the things that may be missing for tljh-repo2docker to just become a binderhub that can run on both a single machine and on k8s would be:

yuvipanda commented 7 months ago

@jtpio I am off on the 19th. Can we do 22nd? I can do 8-9am (although ofc 9am-10am is much better, but may be super difficult for you) pacific then.

yuvipanda commented 7 months ago

@jtpio yes, we'll need to port the UI for building the profile list, and it needs to be stored somewhere. I suspect a lot of what you currently have can be reused.

The list can be dynamically populated - profile_list can be set to a coroutine, which can then read that list from somewhere else easily.

jtpio commented 7 months ago

Can we do 22nd? I can do 8-9am (although ofc 9am-10am is much better, but may be super difficult for you) pacific then.

I think 22nd 9am-10am should work :+1: