JupyterHub and BinderHub Team Meeting - November#
Date: Thursday 19th November 2020
Time: 5 PM UTC
GitHub issue: jupyterhub/team-compass#346
Calendar for future meetings: https://jupyterhub-team-compass.readthedocs.io/en/latest/meetings.html
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:
Tim / Binder / @betatim
Alex / Treebeard / @alex-treebeard (just want to learn/observe)
Sarah / Alan Turing Institute / @sgibson91
Simon / OME, University of Dundee / @manics
David / Software Heritage / @douardda
Mridul / GESIS / @MridulS
Rollin / NERSC / @rcthomas
Min / Simula / @minrk
Richard / Aalto University / @rkdarst
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.
Sarah: 2/4 of the Federation clusters are now running Helm 3! jupyterhub/mybinder.org-deploy#1542
Chris: 2i2c exists!! https://2i2c.org/posts/hello-world/
we will also announce some seed funding soon as well. this funding will pay for me and for georgiana!
we will soon open a position for an “open source infrastructure engineer” to work on the pangeo project. if you or anyone you know is interested, please share! here is a draft of the job post https://deploy-preview-28–cocky-booth-e7ed17.netlify.app/job/osie-pangeo/
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 is a force of nature when it comes to switching to GitHub Actions!
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.
Tim [10minutes]: Use calver and cron job to release repo2docker once a month
what do people think of tagging a release of repo2docker every month using a cron job in github actions? Using something like calver (for example v2020-11 for the November 2020 release) to assign a version to it. Using a cron job feels a bit “radical” but it would solve demand from the community for regular releases and automate our current recommendation of “you should be able to use
master
”.People want to be able to
pip install jupyter-repo2docker
so we need to release to PyPI, not just tag in GitHub.If there was a way to make it easy for people to “install master” while doing
pip install
Tim would favour that but no one knows how to do that.dask calver discussion: dask/community#100
Should we also do this for BinderHub?
potentially more tricky because we need to fit into SemVer syntax for our helm chart versions
It is not required that the helm chart version matches the software version. Tim’s impression is that most helm charts actively try to make the chart and software version “very different” to avoid the impression that they are related.
we already publish a helm chart on every merge into
master
Tim would not change anything about BinderHub for now.
we have some work to do just to restore the old behaviour of publishing a chart for every
master
commit because Travis is out of business.Simon: I agree, repo2docker is much more widely installed than BinderHub, so let’s focus on that first and deal with BinderHub later
Issues asking for releases:
Issues discussing ideas for automating/procedure:
Sarah: There is a GitHub Action for publishing to PyPI too! marketplace/actions
Tim: no opposition, let’s pick a CalVer version without discussing it too long because it seems to turn into a never ending discussion
Simon [5 mins]: Planning to transfer manics/action-k3s-helm to jupyterhub organisation
FYI new additions to binder
Mercurial provider (BinderHub PR, already added to repo2docker)
Software Heritage Identifiers (SWHID) (Proposed addition)
Who uses SWH and how?: It’s an open archive so there are many anonymous users. Online journals are beginning to ask submitters to make sure the software is present in SWH archive. HAL (French repo for scientific open-access papers) -> largest percentage of users come from this use case.
Tim: what about python kubernetes v12 API client?
should henchbot use the “gh-pages published as a webpage” version of the helm charts repo instead of raw github
maybe run henchbot less often?
only consider a “version” ready when it is at least 5min old