jupyter-web-app's `PodDefault` `configurations` are keyed by their label selector's key, not their name about kubeflow HOT 5 OPEN

This bug is also the cause of #6812, which identified how a the jwa fails to handle PodDefaults that have no matchLabels selector

from kubeflow.

This bug appears to also affect the tensorboard web app backend, which has a copy of the same get_poddefaults()

from kubeflow.

I don't understand typescript enough to be certain that the label is intended to be the name of the PodDefault, but given the comments in the spawner_ui_config.yaml I think that's probably true

from kubeflow.

@ca-scribner I'm looking at the code in a little more detail and I see what you're saying. I think both our solutions are not optimal though.

This logic uses the matchLabel key to set a the label on the notebook to true.

For this reason I think we need to use the label of the poddefault instead of the name of the poddefault.

BUT I'm not sure this should be the actual logic. Lets take a look at the issue with my solution . Consider the pod default

metadata:
  name: example
spec:
  annotations:
    karpenter.sh/do-not-disrupt: "true"
  selector:
    matchExpressions:
    - key: some-key
      operator: NotIn
      values: ['true']

In this case the configuration should be "some-key" and selecting that configuration in the dropdown would add the "some-key" label to the notebook. Although due to the matchExpressions that is doing the exact opposite of what we want.

I'm currently at a wall with matchExpressions because what we really want to do use this selector to create a label that conforms to the matchExpressions requirement.

from kubeflow.

@thesuperzapper Do you have any input on the above

from kubeflow.