Modern labels not yet introduced for the pods controlled by deployments etc

[samyuh]

The following labels are missing from the hub pod but are present in the singleuser pod. Is this the intended behavior?

app.kubernetes.io/name
app.kubernetes.io/instance
app.kubernetes.io/managed-by

You can verify this behavior by describing the resource or checking it manually with the command:

helm template chart-release . --values values.yaml

[consideRatio]

I've failed to reproduce this, under metadata.labels, I see all of those labels:

    app.kubernetes.io/name: "jupyterhub"
    app.kubernetes.io/instance: "release-name"
    app.kubernetes.io/managed-by: Helm

(base) ➜  zero-to-jupyterhub-k8s git:(main) helm template jupyterhub --show-only templates/hub/deployment.yaml
---
# Source: jupyterhub/templates/hub/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hub
  labels:
    component: hub
    app.kubernetes.io/component: hub
    app: "jupyterhub"
    release: "release-name"
    chart: jupyterhub-0.0.1-set.by.chartpress
    heritage: Helm
    app.kubernetes.io/name: "jupyterhub"
    app.kubernetes.io/instance: "release-name"
    helm.sh/chart: jupyterhub-0.0.1-set.by.chartpress
    app.kubernetes.io/managed-by: Helm

They are however not part of the spec.selector.matchLabels. To change to the new labels from the old (component, app, release) within matchSelector, would be a change that requires a bit of trouble during upgrade. Due to that, the plan was to phase them in.

From #3404:

This enables us to make a breaking change in z2jh 5 where user servers restarted once or more during z2jh 4 doesn't have to be restarted as part of the breaking change then. If we did it right away, network policy enforcement would fail for old servers for example.

[consideRatio]

I'm sorry, I looked at the deployment's labels, not the pod template's labels - they shouldn't include "jupyterhub.matchLabels" but "jupyterhub.labels".

This makes sense to fix!

I think making the change and having users upgrade will trigger a hub pod restart, which is fine - not breaking.

@samyuh do you want to open a PR and fix it?

[samyuh]

Yes! I can try to work on this during the weekend or later today!