It's possible for individual users to upgrade their JupyterLab version, but by default, users will remain on outdated versions.
JupyterLab recently released version 1.0 (release notes), and I've been using it for nearly a month without problems.
This seems like a good time to force upgrade everyone :)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | dancy | T302086 Set scap minimum python version to 3.7 | |||
| Resolved | None | T247045 Migrate all of production metal and VMs to Buster or later | |||
| Resolved | elukey | T234629 Move the Analytics infrastructure to Debian Buster | |||
| Resolved | • razzi | T231067 Install Debian Buster on Hadoop | |||
| Resolved | elukey | T230724 Upgrade all SWAP users to JupyterLab 1.0 |
Hey Neil, is it something for us (as Analytics) to track or do you need any help/action from us? Not super clear what we'd need to do for JupyterLab..
Sure, I have no idea about jupyterlab so I'll have to dig a bit more into how it is installed/deployed/upgraded etc.. this is why I was asking :)
Change 532726 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[analytics/jupyterhub/deploy@master] Updating jupyterlab dependency to 1.0.9
Change 532726 merged by Ottomata:
[analytics/jupyterhub/deploy@master] Updating jupyterlab dependency to 1.0.9
Updated to JupyterLab 1.0.9 by following the process at https://wikitech.wikimedia.org/wiki/SWAP#Administration. I also manually upgraded this for all existing user venvs as described in the docs. JupyterLab users will start using the new version after they restart their JupyterHub servers.
Change 532785 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[analytics/jupyterhub/deploy@master] Revert "Updating jupyterlab dependency to 1.0.9"
Change 532785 merged by Ottomata:
[analytics/jupyterhub/deploy@master] Revert "Updating jupyterlab dependency to 1.0.9"
Mentioned in SAL (#wikimedia-analytics) [2019-08-27T20:46:17Z] <ottomata> rolling back to jupyterlab version 0.32.1, 1.0.x is not compatible with Stretch's version of nodejs - T230724
After upgrading this morning, T231365: Trouble accessing Jupyter Lab (SWAP) was filed. I discovered that JupyterLab 1.0.x isn't compatible with the version of NodeJS that is available in Debian Stretch. Or at least, something really strange is going on with dependencies when building on Debian Stretch. I think perhaps that we have NodeJS locked to 6.11.0 via our WMF apt repository, and this is causing some strange dependency issues with npm when the JupyterLab wheel is being built.
If you can manually upgrade JupyterLab in your venv and it works, then go ahead! I think we need to sit on this old version until we either A. upgrade notebook servers to Buster (won't be a for a while due to T231067), or B. figure out how to containerize SWAP stuff (which is also a large unscheduled project).
So, after more investigation, I think the reason my upgrade to 1.0.9 failed was because I was upgrading user venvs with the --ignore-installed flag instead of the --force-reinstall flag. This caused files from the other package version to be left around and used. I've just upgraded my JupyterLab back to 1.0.9 on notebook1004 and it seems fine.
I'd be willing to try again if I have some guinea pigs. @Iflorez & @Neil_P._Quinn_WMF perhaps?
After upgrading on notebook1003, iflorez still encountered still had the same strange node dependency issues from yesterday. I don't have time to troubleshoot this now, so we'll have to leave this open.
Thank you for working on this! I'm happy to be your guinea pig in the future if @Iflorez is unavailable.
As FYI stat100[5,8] (Buster nodes) are running with JupyterLab 1.1.0, if anybody wants to test and provide feedback I'd be happy :)
If everybody agrees I'd call this task done. Migrating all users to jupyterlab 1.0 will be probably handled when we'll upgrade stat100[4,6,7] to Buster.
@nshahquinn-wmf what do you think?