JupyterHub and BinderHub Team Meeting#
Date: Tuesday 16th August 2022
Time: 9AM Europe/London
Video conference link: https://meet.jit.si/HubsTeamMeeting
This HackMD: https://hackmd.io/@sgibson91/hubs-team-meeting
GitHub issue: jupyterhub/team-compass#547
Calendar for future meetings: https://jupyterhub-team-compass.readthedocs.io/en/latest/meetings/index.html#meeting-calendar
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#
If you are joining the team video meeting, sign in below so we know who was here. Roll call:
min / Simula / @minrk
Sarah / 2i2c / @sgibson91
Simon / University of Dundee / @manics
Callum / ATI / @callummole
Mridul / GESIS / @MridulS
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.
Sarah: As the Community Strategic Lead, I am hoping to kick off some Outreachy internships, but need help with shaping projects and willing mentors! Please see jupyterhub/team-compass#550
4 rounds of Outreachy over two years
Callum: Turing-prod and turing-staging are both new clusters, redeployed to Uk south. But still having intermittency issues :( jupyterhub/mybinder.org-deploy#2252
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.
Erik: Simon has done work on refactoring BinderHub to be less k8s assuming and its great! See jupyterhub/binderhub#1518.
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.
**Min (10m): **z2jh 2.0 jupyterhub/zero-to-jupyterhub-k8s#2528
Trying to release this for nearly a year!
Ready to do a first beta release (we think?)
Min would like someone who spends more time on z2jh to make the call for a beta release
Erik: one part about how to write the changelog
duplicate changes in beta into main release?
Min: doesn’t view beta as getting release notes, they get a draft of what’s changed which is iterated on up to the main release
agreed to also make this change in z2jh
Erik: agrees z2jh is ready with review of changelog
Simon: Stop mergings PRs, update and review changelog, release beta then start merging again
Action: update the PR, will include jupyterhub 3-beta1
Min (5m): chartpress prerelease tags: jupyterhub/chartpress#150
Not ready yet, but still open for conversation
How we tag prereleases of helm charts
Confusing because latest helm chart is 1.3.1-prerelease because of how we use git describe to generate tags
PR allows us to be explicit about being in a prerelease phase and more intelligible prerelease tags
After we make first prerelease and before we make the first main release, the two behaviours are the same, so there’s still time to iterate
Simon (5m): Pending breaking changes to BinderHub Build class jupyterhub/binderhub#1521
Related to PR linked in the celebrations section, with no breaking changes
New class for the k8s build, old build class became a subclass, but maintenance burden to support both
Suggestion to move to a traitlets-based config, but would mean everyone using old config would need to rewrite config
Erik: If we cause breaking changes, we should have helm template error early before deploying k8s resources because it does not conform to a JSON schema
Min: two levels of breaking, breaking the Python API (not a big-deal, not really supported yet), on a config level it’s moving things from one class to another and can be deprecated softly (log a warning and translate in the background)
Erik: Should we do a hard break in order to keep the code readable and maintainable for us? Or deprecate?
Min: What breaks, and what effort is involved in keeping it from breaking? E.g. Breaking the Python API is under-used and hard to maintain so we should break, whereas config is well-used and easy to fix, so we shouldn’t break it
Simon: will try to keep it non-breaking and will iterate in the PR