When spawning a user's notebook pod, spawner mounts various types of persistent volumes. They include
- User volume
- Group volume (Project volume)
- Data volume
User volume stores users' own data. When a user spawns Jupyter server for the first time, the user's PVC is created.
The capacity is determined in the order
- Use user's specified
- If this setting is not defined, use the max
userVolumeCapacityof all the groups the user belongs to.
- If none of the group set the
userVolumeCapacity, use the system's
The storage class is defined in the helm value.
Group volume (Project volume)
A group volume (project volume) stores the data shared by a group. To enable the group volume, the administrator should enable the
Shared Volume in the group setting. And the volume is created if it doesn't exist at the very first time of the mount to the group volume.
The storage class is defined in the helm value
primehub: sharedVolumeStorageClass: "<rwx-storage-class>"
But in most cases, we use an NFS pvc provisioned by
primehub-groupvolume-nfs. The configuration would look like this
primehub: sharedVolumeStorageClass: "" groupvolume: storageClass: standard
- the group volume is manually provisioned
primehub-groupvolume-nfscontroller would create an NFS server backed by an RWO pvc
- the RWO pvc uses a "standard" storage class.
If you didn't specify primehub-group-sc's value ("standard" here) in yaml, it will be set by
Currently, there are these types of the data volume would be mounted as persistence volume
If the data volume is the type of
pv, the data volume is backed by a pvc. The difference comparing to group volume is
- A data volume can be connected to multiple groups; while group volume only belongs to a group
- The connection from data volume to a group can be read-only or read-write
- Can enable an upload server
Under the hood, the storage class is defined in the helm value
groupvolume: storageClass: standard
It will create an NFS server backed by an RWO pvc which is similar to group volume.
If you didn't specify a value ("standard" here) in yaml, it will be set by
metadata.namein the CRD and the
spec.volumeNamein the CRD.
If the data volume is a type of
git, the data volume is backed by a hostpath and periodically pulls the data from a repository. Under the hood, we use gitsync daemonset to sync the data to hostpath
In this way, the data volume is not backed by a pvc, instead, the volume is a nfs volume
|nfs||server and path settings|
In this way, the data volume is not backed by a pvc, instead, the volume is a hostpath volume
|The mount path of the pv data volume.|
|Whether a symbolic link to the mountPath is required.|
|The host path to put the gitsync result.|
|The mount path of the git data volume|
|Mount only when the launching group connects this dataset|
|Only works in pv type data volume. Create an upload server.|
|Only works when an upload server is created. Set http basic auth based on secret.|
Symbolic links in the home folder
The home folder is mounted by the user volume. However, in order to locate the project volume and data volume easily, we create symbolic links in the home folder.
- Group Volumes:
- Data Volumes:
The symbolic links to a data volume can be removed by setting the annotation
Launch group only
By default, if a user has permissions to access the group volume or a data volume, the spawner would mount it no matter which group the user selects.
But if a group volume or a data volume is configured
Launch Group Only to
no. The volume is only mounted while the user selects the group which connects to this volume.