JupyterHub and BinderHub Team Meeting#

By participating in this meeting, you are agreeing to abide by and uphold the Code of Conduct. Please take a second to read through it! :pray:

Welcome to the Team Meeting#

Hello!

If you are joining the team video meeting, sign in below so we know who was here. Roll call:

  • Erik Sundell / Sundell open source / @consideRatio

  • Sarah Gibson / 2i2c / @sgibson91

  • Wayne Decatur /Upstate Medical University / @fomightez

  • AT Darian / QuantStack / @afshin

  • Simon Li / University of Dundee / @manics

  • Eskild Eriksen / Quansight / @iameskild

  • Min / Simula / @minrk

  • Luke / Alan Turing Institute / @lukehare

  • Rollin / NERSC / @rcthomas

  • Samuel Gaist / Idiap / @sgaist

Quick updates#

60 second updates on things you have been up to, questions you have, or developments you think people should know about. Please add yourself, and if you do not have an update to share, you can pass.

Reports and celebrations#

This is a place to make announcements (without a need for discussion). This is also a great place to give shout-outs to contributors! We’ll read through these at the beginning of the meeting.

Agenda items#

Let’s collect all potential agenda items here before the start of the meeting. We will then attempt to create a coherent agenda that fits in the 60m meeting slot. If there are similar items try and group them together.

  • Sarah (10 mins): New Binder Federation member on AWS supported by Pangeo/NSF/2i2c

    • migrating pangeo hub to 2i2c management

    • what is the value in pangeo running separate binder instance?

    • Why not a federation member instead?

    • Our first AWS member

    • 2i2c would be the ‘operator’ of the cluster

    • Q: how ‘different’ would it be, if at all? (A: not keeping dask gateway, at least)

  • Darian: Jupyter Software Steering Council representative, JupyterHub team-compass, etc.

    • Jupyter adding Councils across subprojects

    • JupyterHub has similar roles, but updating to match expected names

    • Refreshing team membership #566

    • Motivation for update: Jupyter SC is too large, but was our only ‘recognition’ mechanism for a while

    • Want to make voting easy, and ‘inactivity’ impersonal and not punitive (easy to come back)

    • Security also relevant: folks not using code privileges shouldn’t have them

    • Councils should be about decisions, not tool permissions

    • Governance call every Monday, same time as this meeting

  • Erik: Cleanup in Jupyter + JupyterHub dockerhub organization

    • Background: the hub.docker.com organizations jupyter and jupyterhub are now in an open source program, granted some bells and whistles. They ask that we document all our image repositories to the extent that they for example link to related source code - not much, but a little.

    • It seems though that before documenting 4-5 year old images that hasn’t been pushed to for a long time, we can instead delete some very outdated images.

    • Action points:

      • Min can add some notes and links for older images, if other folks don’t remember what they are

      • Security fixes for archived images is a later topic

    • jupyterhub/team-compass#559

  • Erik: Technical inputs about possibly creating a jupyterhub service for repo2docker

    • input on choice for a jupyterhub service’s webserver (tornado, fastapi, flask, etc.)?

      • authentication and authorization against jupyterhub

      • making it more likeley that it can become a jupyterhub project long term by using known tech etc

    • input on choice of a jupyterhub service’s frontend tech (react, etc)

      • want to make it easy to contribute to, maintain

      • ‘jupyverse’ is Jupyter Server on FastAPI

      • FastAPI seems more like ‘the future’ with data classes, ASGI, etc.

      • tornado not moving forward much

      • Lots of knowledge in tornado, but we don’t want to be stuck on one stack

      • Based on BinderHub, what in BinderHub do you not want to keep? Learn from a previous app that does something similar

      • What about frontend technology?

        • lumino is something to consider, can provide menu, shortcut, panel etc. If we would build a UI within JupyterLab to use thi service, then using lumino can make it easy!

        • Class: JupyterFrontEnd, from jupyterlab application package, to create an arbitrary frontend etc. Allows you to load a frontend extension from JupyterLab.

        • There is also jupyterlab-contrib/jupyterlab-app-cookiecutter

        • lumino is also a good choice if you want to embed UI in a JupyterLab extension

        • QuantStack is working on a hub-like app with lumino/jupyterlab UI for consistent experience across hub(ish)->lab

        • QuantStack has hired a Jupyter-focused UX designer, who may be available to help with mocking up JupyterHub-related UI