User home directory storage#
All users on all the hubs get a home directory with persistent storage.
This is made available through cloud-specific filestores and sometimes through a manually-managed Network File System (NFS) (usually this is the case on GCP clusters that are very price sensitive).
NFS Server provisioned setup#
Terraform is setup to provision the in-cluster NFS server using the following cloud specific implementations.
GCP: Google Filestore
AWS: Elastic File System
NFS Server setup - only for manually managed servers#
No longer the default option!
Use this as a last resort only on GCP clusters that are very price sensitive. Use the cloud-specific filestore as default instead.
Some of the 2i2c clusters has a NFS server that is usually located at
nfs-server-01. This is currently hand configured, so it might change in the future. This NFS Server has a persistent disk that’s independent from rest of the VM (it can be grown / snapshotted independently). This disk is mounted inside the NFS server at
/export/home-01 (for the home directories of users) and is made available via NFS to be mounted by everything in the cluster, via
To SSH into the NFS server run:
gcloud compute ssh nfs-server-01 --zone=us-central1-b
NFS Client setup#
For each hub, there needs to be a:
A directory is created under the path defined by the
nfs.pv.baseShareName cluster config.
Usually, this is:
/homes- for hubs that have in-cluster NFS storage
Created using the infrastructure described in the terraform section.
/export/home-01/homes- for hubs that have the NFS server deployed manually
This the the base directory under which each hub has a directory (
This is done through a job that’s created for each deployment via helm hooks that will mount
nfs.pv.baseShareName, and make sure the directory for the hub is present on the NFS server with appropriate permissions.
The NFS share creator job will be created pre-deploy, run, and cleaned up before deployment proceeds. Ideally, this would only happen once per hub setup - but we don’t have a clear way to do that yet.
Hub user mount#
For each hub, a PersistentVolumeClaim(PVC) and a PersistentVolume(PV) are created.
This is the Kubernetes Volume that refers to the actual storage on the NFS server.
The volume points to the hub directory created for the hub and user at
(this name is dynamically determined as a combination of
nfs.pv.baseShareName and the current release name).
Z2jh then mounts the PVC on each user pod as a volume named home.
Parts of the home volume are mounted in different places for the users:
Z2jh will mount into
/home/jovyan(the mount path) the contents of the path
<hub-directory-path>/<hub-name>/<username>on the NFS storage server. Note that
<username>is specified as a
subPath- the subdirectory in the volume to mount at that given location.
Mounted for all users, showing the contents of
<hub-directory-path>/<hub-name>/_shared. This mount is readOnly and users can’t write to it.
Mounted just for admins, showing the contents of
<hub-directory-path>/<hub-name>/_shared. This volumeMount is NOT readonly, so admins can write to it.
This feature comes from the custom KubeSpawner that the our community hubs use, that allows providing extra configuration for admin users only.
allusersdirectory - optional
Can be mounted just for admins, showing the contents of
<hub-directory-path>/<hub-name>/. This volumeMount is NOT readonly, so admins can write to it. It’s purpose is to give access to the hub admins to all the users home directory to read and modify.
jupyterhub: custom: singleuserAdmin: extraVolumeMounts: - name: home mountPath: /home/jovyan/allusers