Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI for building the environments #78

Open
jtpio opened this issue Jan 19, 2024 · 10 comments
Open

UI for building the environments #78

jtpio opened this issue Jan 19, 2024 · 10 comments

Comments

@jtpio
Copy link

jtpio commented Jan 19, 2024

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:
  1. Make tljh-repo2docker work with both TLJH and ZTJH

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
Copy link
Author

jtpio commented Jan 19, 2024

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

@damianavila
Copy link

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

@yuvipanda
Copy link
Member

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
Copy link
Member

choldgraf commented Feb 13, 2024

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
Copy link
Member

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
Copy link
Member

choldgraf commented Feb 14, 2024

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
Copy link
Author

jtpio commented Feb 14, 2024

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:

  • the UI for building environments, accessible to hub admins (or a specific group of users via the JupyterHub groups?)
  • a way to list the built environments, to show them in the admin UI and in the profile list. For now it seems this list needs to be updated via the config, and can't be populated dynamically? Also the images may live locally on the host machine or in a registry in the case of k8s

@yuvipanda
Copy link
Member

yuvipanda commented Feb 14, 2024

@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
Copy link
Member

@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
Copy link
Author

jtpio commented Feb 15, 2024

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 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: No status
Development

No branches or pull requests

4 participants