code-server: user settings not persisted

[vexingly]

Describe the bug

The version of code-server that we bundle the juypterlab docker image has a bug where the user settings are stored only in the browser and not on the file system. Now that kubeflow can deallocate notebook servers this causes the settings to be lost and users need to reapply them every time.

Environment info

Default jupypterlab notebook

Steps to reproduce

Steps to reproduce the behavior:

1. Start juypterlab notebook
2. Launch vs-code
3. Make changes to vs-code user settings
4. Stop/start your notebook
5. Launch vs-code
6. Settings have been reset

Expected behaviour

Settings should be saved to the filesystem so they are persistent

Additional context

Current version: 3.10.2-nodownload-v3 https://github.com/StatCan/aaw-kubeflow-containers/blob/master/docker-bits/6_jupyterlab.Dockerfile

Upstream bug: https://github.com/coder/code-server/issues/4609 Resolution: https://github.com/coder/code-server/pull/4631

Possible issue, if multiple people share a notebook then the user settings persisted to disk would apply to all users... but at least if loaded from disk they can be backed up.

Relates to: https://github.com/StatCan/aaw-kubeflow-containers/issues/337

[Souheil-Yazji]

Created https://github.com/StatCan/aaw-kubeflow-containers/pull/375 to upgrade VS code-server. More details in PR regarding changes. Currently blocked due to CI failing.

[Souheil-Yazji]

Blocked by https://github.com/StatCan/aaw-kubeflow-containers/issues/376 and https://github.com/StatCan/daaas-private/issues/16

[Souheil-Yazji]

Update: It seems that updating VS code server does not presist the user settings. Reason 1 (most likely): The settings.json file is saved in etc/share/code-server/User. I don't think this directory is presisted when the notebook is shut down, I wanted to test by writing a file to it and restarting the notebook but sudo is needed to write to the directory. This reason is further reinforced due to the fact that only the mounted presistent storage is presisted as far as my understanding goes, and the default mount is home/jovyan.

see https://github.com/StatCan/aaw-kubeflow-containers/blob/master/docker-bits/6_jupyterlab.Dockerfile#L29-L31

ENV XDG_DATA_HOME=/etc/share
ENV SERVICE_URL=https://extensions.coder.com/api
COPY vscode-overrides.json $XDG_DATA_HOME/code-server/User/settings.json

The solution may be to change $XDG_DATA_HOME to be in the user presisted directory More on XDG here https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

https://github.com/coder/code-server/issues/1279 Also hints towards changing the $XDG_DATA_HOME var

[Souheil-Yazji]

User settings successfully persisted by changing the $XDG_DATA_HOME env var to a persisting location. An issue remains, https://github.com/StatCan/aaw-kubeflow-containers/blob/master/resources/common/vscode-overrides.json is still being written over the user settings. I tried the following:

if [! -f "$VS_CODE_SETTINGS" ]; then
    cp vscode-overrides.json "$VS_CODE_SETTINGS"
fi

but this doesn't work because it seems that the settings file is initialized and therefore this would not execute. Some alternatives:

• Remove the default settings override (simplest solution): dark mode would be removed, extensions would auto-update (this is my choice)
• Apply the settings override at the remote level. Levels exist for vscode server settings: workspace, user, remote. When a user changes their settings, the User/settings.json file is changed. They also have the choice to change the remote settings. See more details in https://code.visualstudio.com/docs/getstarted/settings#_settings-precedence. Unfortunately some settings are scoped to certain levels. In our case "extensions.autoUpdate": false is scoped at the user level, so I can't see how we'd retain this setting.

[vexingly]

It looks like auto-update is being disabled due to https://github.com/StatCan/daaas/issues/463, but this solution looks to be caused by the old version of vs code... with the version being updated we could remove this setting (and remove the python extension pinning?) leaving only the theme that could be added at the higher level if it's deemed we still need it! What do you think about that issue @Jose-Matsuda ?

[Jose-Matsuda]

Honestly that seems pretty good