volume app list pvcs facing 404 error after upgrade kubeflow from v1.7 to v1.8

[cybernagle]

/kind bug

What steps did you take and what happened:

1. open kubeflow
2. navigate to volumes
3. get 404 error when listing all pvcs.
4. if I navigate it to Notebook, and select specific volume. we can get the volume information.
5. when we rollback volumes application from v1.8 to 1.7. and keep central dashboard and other components as v1.8, list pvcs(volumes) is back.

What did you expect to happen:
once navigate to volumes, we should able to see all the volums

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
seems like it related to this PR.
f4f8bf1#r133012688

Environment:

• Kubeflow version: (version number can be found at the bottom left corner of the Kubeflow dashboard): v1.8
• kfctl version: (use kfctl version): not using
• Kubernetes platform: (e.g. minikube) kubernetes v1.26.0
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

[bwhartlove]

Commenting here for tracking. I ran into the same issue when upgrading from 1.7 to 1.8.

[GoIemXIV]

Met the same issue when upgrading from 1.7

[thesuperzapper]

Thanks for raising this we are tracking a fix for 1.8.1 in #7453 (comment)

@cybernagle @bwhartlove @GoIemXIV To help further, can someone provide error logs (probably showing the Python error) from their volumes-web-app pod?

[cybernagle]

sorry for the late reply, currently I've downgrade volums-web-app from 1.8 to 1.7 and issue disappared , and it's running under heavy load traffic hence we can not do the upgrade.
I'll try to setup a new environment to reproduce this issue. :)

[cybernagle]

f4f8bf1#r134991040

☝️ in case anyone needed, another recommand solution upon .
thanks for @abaland

[kimwnasptd]

Did a fresh 1.8 install and could not reproduce this issue.

Looking at the comments above and from the PR commits it looks like the issue for folks is that they run the Volumes web app but without running the PVCViewer Controller.

@cybernagle can you confirm if this issue persists when you have pvcviewer controller installed? And if it does, can you share the logs from the backend of the volumes web app?

[thesuperzapper]

@kimwnasptd do you think we should support the case that the PVC Viewer is not installed, without failing?

[kimwnasptd]

@thesuperzapper it'll be a bit more involved to achieve this. It'll require some changes in the frontend as well so that:

1. The backend will need to make a request to detect PVCViewers CRD is not present (not that difficult)
2. The frontend can also know when to not show the file-browsing icon per PVC (need to query backend)

It's not the most technically challenging work, but comes to if we want PVCViewer Controller to be a hard dependency of the web app

[thesuperzapper]

@kimwnasptd we probably need to be more clever than just detecting if the CRD is present, because its not really possible to remove CRDs, and a user might install the Viewer, and then decide they no longer want it.

Probably it just makes sense to have a startup arg for the volumes web app, so users can decide if they want the additional security risk of spawning viewer pods.