pvc_name is expanded before user options/profiles are loaded

[manics]

Bug description

pvc_name is expanded in __init__, which means pvc_name_template can't be overridden in kubespawner_overrides:

kubespawner/kubespawner/spawner.py

Line 208 in 5ac45e9

self.pvc_name = self._expand_user_properties(self.pvc_name_template)

How to reproduce

Reported in https://discourse.jupyter.org/t/creating-1-pvc-per-profile-and-per-user/31755

With Z2JH 4.1.0:

hub:
  db:
    type: sqlite-pvc

proxy:
  service:
    type: NodePort
    nodePorts:
      http: 31080

singleuser:
  profileList:
    - display_name: "profile1"
      description: "desc1"
      kubespawner_override:
        pvc_name_template: claim-{username}-profile1
    - display_name: "profile2"
      description: "desc2"
      kubespawner_override:
        pvc_name_template: claim-{username}-profile2

debug:
  enabled: true

Expected behaviour

pvc_name follows the template pvc_name_template if it is overriden in kubespawner_overrides.

Actual behaviour

The overridden template is ignored, claim-{username} is used for all profiles.

Your personal set up

https://killercoda.com/manics/scenario/jupyterhub-kubernetes

[minrk]

I think this is open as #761 with a proposed fix in #820

The hang-up I have is in how do we distinguish intended pvc name changes from those that aren't. If a deployment changes the pvc_name_template that affects existing servers which have previously launched with a pvc, should it:

1. keep the existing pvc (prefer state to config)
2. create a new pvc (prefer config to state)
   a. if so, what to do with the old one?

Unfortunately, the answer is pretty clearly it depends, so the question really becomes: how do we allow deployments to express that choice in config. Then I think we can finish #820 and fix this.