Extend KubeSpawner and its UI to handle Persistent Volume Claims

[jlewi]

In the JuptyerHub spawner you can specify Docker image and resource requirements. It would be nice if you could also specify volume claims and mount points so that users can easily attach shared volume to their notebooks.

According to jupyterhub/jupyterhub/issues/1580 we can do this just by adding some properties to our KubeSpawner.

[foxish]

I'm not sure if it's intuitive to have the user specify PVCs and mount points, as opposed to just requesting resources (as they currently do). It runs a bit afoul of the broad goal of making infrastructure "disappear" IMO. Maybe we can have a single place to do advanced config, which can be enabled by jupyterhub/kubespawner#111

[jlewi]

@foxish I'm not sure I understand the distinction you are drawing between resources and PVCs? In this case a PVC seems like a resource in the same regard as CPU/RAM/GPU.

[foxish]

My point was that PVCs are a much more K8s-specific construct as opposed to CPU/RAM/GPU. As I understood, we wanted to hide the complexity of k8s concepts from the user - but this is still probably useful for advanced users. IIRC, JupyterHub in kubeflow already uses PVCs under the hood for notebook storage right now. Is there a use-case driving exposing arbitrary mounts and PVCs?

[jlewi]

So I think the use case is as follows.

People have a bunch of existing NFS servers or other types of storage systems that they want to bind to their Jupyter notebooks so that they can access data on those shares.

There are generally two approaches to this

1. We could make it possible for people to modify their JupyterHub/KubeSpawner config so that certain PVC's get attached to every notebook.

2. We can modify the spawner UI so that users can specify which PVCs to attach to their notebooks.

I think I lean towards #2. The advantage of #2 is that you don't have to redeploy to attach a newly created PVC.

Furthermore, #2 seems better suited to the case where we allow users to spawn multiple Jupyter notebooks which is a direction I think we want to move in.

My philosophy for Kubeflow is that we should expose K8s concepts/abstractions when it makes sense rather than introducing new ones.

PV/PVC is one of those abstractions that I think we should expose; I don't think we can avoid dealing with storage and PV/PVC is a great abstraction.

@pdmack any interest in trying to tackle it?

[pdmack]

@jlewi I'll have a go. Probably have more questions as I begin the journey.

[jlewi]

One idea I had was to generate the jupyterhub_spawner.py file using an init container. This would allow us to be more dynamic; e.g. we could make a K8s API request to see if there is a default storage class defined or not and adjust the config accordingly.

[pdmack]

Yeah, I mean the KubeSpawner embeds the python k8s client so I was assuming that we could do some introspection from the hub pod itself. But init container might be worthwhile as a separation of concerns and a place to generally store "outward" facing logic. The hub UI will still need to reflect what comes back to it though.

[pdmack]

/assign @pdmack