UI overrides mountpath specified in `spawner-ui-config.yaml`

[gigabyte132]

/kind question /kind bug

What steps did you take and what happened:

1. Configured a data volume mount in the spawner-ui-config.yaml file with the following specification:

   dataVolumes:
    value:
      - mount: /cvmfs
        mountPropagation: HostToContainer
        existingSource:
           persistentVolumeClaim:
             claimName: "cvmfs"

2. Proceeded to start to create a new notebook and checked on the default data volume to be created/attached (have tried both options to create a new volume and attach an existing one) The get request backend correctly interpreted the mount path as '/cvmfs' as mentioned in spawner-ui-config.yaml.

However, the Jupyter Web App UI defaulted to /home/jovyan/cvmfs instead of the specified /cvmfs.

What did you expect to happen: The Jupyter Web App UI should respect the mount path specified in the spawner-ui-config.yaml file and display /cvmfs as the default mount path in the UI.

Anything else you would like to add:

As a workaround, I was able to resolve this using a PodDefault to set the correct mount path. However, this should not be necessary if the UI correctly interprets the spawner-ui-config.yaml.

This behavior makes it difficult to customize mount paths directly through the spawner-ui-config.yaml, which is important for our use case, as we have a number of filesystems that should ideally be mounted at /.

Miscellaneous information that will assist in solving the issue:

From looking around in the frontend codebase the /home/jovyan path seems to be hardcoded in a bunch of methods, e.g.

  updateMountPath(volGroup: FormGroup, nameCtrl: AbstractControl) {
    const mountPathCtrl = volGroup.get('mount');
    this.valueChangeSubscription = nameCtrl.valueChanges.subscribe(v => {
      const mount = v;
      if (mountPathCtrl.dirty) {
        this.valueChangeSubscription.unsubscribe();
        return;
      }
      volGroup.get('mount').setValue(`/home/jovyan/${mount}`);
    });
  }

I mostly want to know if this is intended, if yes why, and if not I'd be happy to contribute with a PR to change this.

Environment: Kubeflow version: (version number can be found at the bottom left corner of the Kubeflow dashboard): 1.8 Kubernetes platform: (e.g. minikube) Vanilla K8s Kubernetes version: (use kubectl version): Client Version: v1.29.6 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.28.4 OS (e.g. from /etc/os-release): Fedora CoreOS 39