Issue triage report

[consideRatio]

I have looked through issues and PRs and felt it would be useful to write a summary of what I observed are common wishes and trouble.

User based config before spawn

This theme regards the profile_list configuration and improving the Spawner generic ability to declare what the user should be able to choose and have right to choose.

Related issues / PRs

Notes:

• There is discussion in wrapspawner, kubespawner, and jupyterhub about moving functionality to the main repository which currently resides in individual spawners that all inherit from the Spawner base class.

Additional user resources per user (namespaces, services, secrets etc.)

There can be use of a dedicated k8s Secret resource per spawned server #398, or a dedicated k8s Service (#425), or a dedicated namespace (#218, #387), or just generally more resources (#115).

Related issues / PRs

Notes:

• KubeSpawner interacts with the k8s api-server just like kubectl does, and have permissions to do very specific things with specific resources in the local namespace. All of these kinds of features will require additional k8s RBAC permissions to be requested along with them so for example KubeSpawner is allowed to create a k8s Secret resource.
• By creating more resources, the need to be able to clean them up becomes bigger and bigger. For example, what should happen if a user is deleted by JupyterHub? For these kinds of considerations, want to highlight Let spawners cleanup resources on user/named-server deletion jupyterhub#3197 and this label.

Multiple deployments in a single namespace

To support multiple deployments of a JupyterHub using a KubeSpawner in the same namespace require some changes in Z2JH (jupyterhub/zero-to-jupyterhub-k8s#1791), but KubeSpawner specifically could already be tweaked to support this by configuring component_label.

KubeSpawner labels the resources it creates and keeps track of them using reflectors. We want KubeSpawner to only focus on those part of its own deployment, and this is done by selecting only resources of a certain set of labels. This set currently is represented by component: singleuser-server by default for the pods, but we can make it component: singleuser-server-hub1 or similar by setting c.KubeSpawner.component_label = "singleuser-server-hub1".

What I'd like us to do is to allow KubeSpawner to instead have a configurable set of matchLabels like a k8s Deployment keeps track of its pods with matchLabels. Then we can have app.kubernetes.io/component: singleuser-server and app.kubernetes.io/instance: hub1 or similar which together single out the relevant Pods, and not compromise on using the component label to both describe what kind of component it is and what installation of JupyterHub/KubeSpawner created it.