You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The docker container is wonderful, except that it is difficult to provide data persistence. Currently, sage is installed into the sage user's home directory. This prevents an administrator from leveraging a single podman (or docker) volume to persist data that sage, jupyter, or any of the other tools may create.
As it is now, each of these potential homedir subdirectories needs to be discovered and handled separately, cluttering up both the command line invocation as well as the volumes themselves (if not using bind-style volumes), as one can't mount a volume to the homedir path while leaving it's contents intact.
Proposed Solution
In the containers, change the installation to occur under a subdirectory of /opt instead, allowing the sage user's whole home directory to remain (mostly) empty. Items such as .bashrc are likely not relevant (I have not actually checked to see if they are just copies from /etc/skel or have been customized)
This would allow the following sort of usage to be trivial:
podman volume create whatever
podman run -it -v whatever:/home/sage:rw docker.io/sagemath/sagemath:latest
One can go even further with this sort of deployment, setting up the container via a systemd quadlet such that a notebook starts when the user logs into the system.
Alternatives Considered
I have considered other methods, such as setting the XDG_* environment variables to a location that can be a volume - however, this isn't perfect as software often does not respect these variables.
One can also copy the container's homedir into a volume, and then mount that volume over it on later runs. While this does work, it requires the user to handle upgrades manually (ie the container runtime environment and the sage install will immediately fall out of sync if a new image is pulled)
Additional Information
No response
Is there an existing issue for this?
I have searched the existing issues for a bug report that matches the one I want to file, without success.
The text was updated successfully, but these errors were encountered:
Problem Description
The docker container is wonderful, except that it is difficult to provide data persistence. Currently, sage is installed into the sage user's home directory. This prevents an administrator from leveraging a single podman (or docker) volume to persist data that sage, jupyter, or any of the other tools may create.
As it is now, each of these potential homedir subdirectories needs to be discovered and handled separately, cluttering up both the command line invocation as well as the volumes themselves (if not using bind-style volumes), as one can't mount a volume to the homedir path while leaving it's contents intact.
Proposed Solution
In the containers, change the installation to occur under a subdirectory of /opt instead, allowing the sage user's whole home directory to remain (mostly) empty. Items such as .bashrc are likely not relevant (I have not actually checked to see if they are just copies from /etc/skel or have been customized)
This would allow the following sort of usage to be trivial:
One can go even further with this sort of deployment, setting up the container via a systemd quadlet such that a notebook starts when the user logs into the system.
Alternatives Considered
I have considered other methods, such as setting the XDG_* environment variables to a location that can be a volume - however, this isn't perfect as software often does not respect these variables.
One can also copy the container's homedir into a volume, and then mount that volume over it on later runs. While this does work, it requires the user to handle upgrades manually (ie the container runtime environment and the sage install will immediately fall out of sync if a new image is pulled)
Additional Information
No response
Is there an existing issue for this?
The text was updated successfully, but these errors were encountered: