JupyterHub and BinderHub Team Meeting#
Date: Thursday 21st January 2021
Time: 5 PM UTC
GitHub issue: jupyterhub/team-compass#364
Calendar for future meetings: https://jupyterhub-team-compass.readthedocs.io/en/latest/meetings.html
Welcome to the Team Meeting#
If you are joining the team video meeting, sign in below so we know who was here. Roll call:
Min / Simula / @minrk
Mridul / GESIS / @MridulS
Nick / Turing / @nbarlowATI
Sarah / Turing / @sgibson91
Ivana / Simula / @IvanaH8
Hassan / KAUST / @Hassan-Alzahrani
Wayne / Upstate Med University/ @fomightez
Tim / Binder / @betatim
Simon / University of Dundee / @manics
Rollin / NERSC / @rcthomas
Carol / Jupyter and Noteable / @willingc
Isabela / Quansight Labs / @isabela-pf
Erik / Sundell open source / @consideratio
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.
Happy new year everyone! 🎉
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.
KubeSpawner has user namespace support! Thanks @athornton! jupyterhub/kubespawner#458
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.
Erik (15 min): progression of compromises associated with low maintainer capacity
Consider a massive open source project. It can have a strict set of practices for any changes (enhancement proposals, multiple approvals, pre-releases, extensive test coverage, changelogs, etc). Smaller projects couldn’t sustain such practices though. My point of discussion regards what practices we look to sustain for various repos in the JupyterHub github organization.
Feedback on how I’ve acted:
I’ve self merged PRs about CI system, obvious bugfixes, etc.
I’ve tried to make it as easy as possible for PR reviews
I’ve made time delayed self-reviews of PRs so they are in as good shape as possible
I’ve self-merged carefully considered PRs and opted put in additional attention post-merge to ensure it didn’t cause trouble.
What and when can we compromise on various practices?
Carol: Time sensitive: go ahead, self-merge. Will it break functionality? Don’t self-merge. Maintainers, use your best judgment. Don’t want to create a situation where ~20 PRs have been merged whenever you touch the repo.
org status report tools (developed by Carol)? Talk to Tania and Isabela at Quansight to automate something for us?
Tim: PR review sounds like journal review - mostly it’s not like that in our org. It should be a check, but also keep people up-to-date so PR creator is not the only one who knows how it works. Does the fact that we have loads of open issues/PRs open matter?
Simon: Maybe long open lists does matter? Looks bad, looks like things has been ignored
Sarah: Advocate to the community that it’s ok to take over PRs? Pull Request of the month?
Min: As number of issues/PRs grows, it becomes difficult for maintainers to keep track of where their focus should be
Zach: dedicated meeting/time to check over these things
Tim: The size of the PR is almost always uncorrelated to the ease of review
Tim (10min): new federation member
have two fairly beefy machines but would need us to deploy our own k8s clusters on bare metal.
This is now 4 machines!!
If Hassan and his team can provide the Kubernetes deployment, this is an easy yes for us to take on. Mridul can provide advice on on-prem deployments of k8s.
Feeling is that it is worth trying to make this happen.
Min (5min): Minesweeper for in-cluster-deployed detection
Mridul (5min): Participation in Google Summer of Code? JupyterHub/BinderHub?
Nick and Piero (10 mins (Piero might not be able to join before 5:30 GMT)): Custom Jupyterhub spawner for Azure Machine Learning
As part of the Turing’s “Pangeo-on-Azure” project, we have been working with a team at the Met Office Informatics Lab to develop a spawner that provisions Azure Machine Learning Compute Instances on behalf of users, with JupyterLab servers running on them.
Not easy for a user to shut down their server
Difficult to get IP of the AML VM (running behind a gateway)
Simon: manics/jupyterhub-ansiblespawner is along vaguely similar lines
This meeting overran - sorry! :grimacing: I have moved the below point to an issue: jupyterhub/team-compass#368
Min (2min): Attach meeting time to timezone that observes daylight savings? (an hour later in winter). I get the sense that the earlier time isn’t great for folks, and we don’t have to use UTC for everything.
:+1: tim, erik
Sarah: Does this mean 9am/6pm in winter, 8am/5pm in summer?