Document caveat about pod_name_template

UPDATE by Erik

See https://github.com/jupyterhub/kubespawner/issues/528#issuecomment-930142207, we should make sure the docs is clarifying this.

---

Bug description

It looks like it is not possible to change the default pod-naming strategy jupyter-{username}--{servername}.

Expected behaviour

KubeSpawner should allow changing pod naming approach

Actual behaviour

I used three different variants and none of them works: 1.

singleuser:
    podNameTemplate: podname-{userid}

singleuser:
    profileList:
        - display_name: test
            kubespawner_override:
                pod_name_template: override-{userid}

hub:
    extraConfig:
        kubeSpawnerCfg: |
            c.KubeSpawner.pod_name_template = "config-{userid}"

I even tried all three at once, but I’m getting default jupyter-{username}--{servername} 😄

I also tried to dive into sources and I cannot find an issue on zero-to-jupyterhub-k8s side. I suspect changing this value could be not supported by kubespawner itself:

1. pod_name_template is used only at Spawner initialization time: https://github.com/jupyterhub/kubespawner/blob/master/kubespawner/spawner.py#L214
2. the rest of the code seems to use already generated pod_name, for example this one looks like pod creation request: https://github.com/jupyterhub/kubespawner/blob/master/kubespawner/spawner.py#L1817-L1818
3. so far I cannot find how exactly z2jh applies the configuration, but I think it tries to change the naming template after KubeSpawner is initialized

If you could help to confirm or deny my findings, I think I can help to solve the issue

How to reproduce

Use snippets from Behavior section

Your personal set up

Kubernetes: v1.19.7
Helm: v3.6.0
Jupyterhub charts: 0.11.1-1.0.0

[v1r7u]

An intermediate update

1. it looks like singleuser.podNameTemplate: podname-{userid} and hub.extraConfig.kubeSpawnerCfg: c.KubeSpawner.pod_name_template = "config-{userid}" can work, but… 😄
2. if pod is created the very first time.

When I was running tests, I created my notebook first with default naming strategy, then I tried to adjust the template, but jupyterhub used the previous name (recorded in db?). Thus, I made a conclusion that these property changes do not work at all

I’ll do a few more tests next week

[v1r7u]

@consideRatio

1. I’m running helm-chart 1.0.0 with rbac and ingress naming changes on top (my two previous PRs)
2. In my kubernetes cluster I have the following image pulled from central docker-hub: image: jupyterhub/k8s-hub:1.0.0. To be precise, Image ID: docker.io/jupyterhub/k8s-hub@sha256:e778c8c72075cf2445cf574b9c5c9bfb2f0572ac70fecb52b05368ca7508640b
3. here is my complete singleuser config section applied on top of default values from the chart:

        singleuser:
          podNameTemplate: jupyter-two-{username}
          cloudMetadata:
            blockWithIptables: false # this property DISABLES creation of privileged init-container
          storage:
            dynamic:
              storageClass: ...
              pvcNameTemplate: claim-{userid}
              volumeNameTemplate: volume-{userid}
            homeMountPath: /home/jovyan
          defaultUrl: /lab
          cpu: # CPU resources should be float
            guarantee: 0.2
            limit: 1
          memory:
            guarantee: "1024M"
            limit: "4096M"
          profileList:
            - display_name: "Jupyter all-spark-notebook"
              default: true
              kubespawner_override:
                image: my-private-registry/jupyter/all-spark-notebook:1.4.0
                cmd: /usr/local/bin/start-singleuser.sh

          extraEnv:
            http_proxy: {{ .Values.proxy }}
            no_proxy: {{ .Values.Noproxy }}

All the values from this list are successfully applied except podNameTemplate 🤷

p.s. Just for the context, we are trying to run multiple jupyterhub instances in the same kubernetes namespace.

I’ve just run out of ideas at the moment. We already spent quite a lot of time making it work and we finally classified this issue as not critical. I’m still curious why it happens, but know it moves to my spare time debugging 😄 If I come up with more ideas or proofs, I will update the thread here.