Closed jayanthshimoga closed 4 months ago
Caused by https://github.com/rapidsai/jupyterlab-nvdashboard/pull/188.
0.10a10
is the last version that has a correct base url.
We're having the same issue with the lastest (0.11.0a5). I haven't tried @jayanthshimoga 's patch, but the original does not honor the baseUrl. We run JupyterLab 4.1.6 on Kubeflow.
Tagging @AjayThorve
Thanks @ajayrgb , I am looking into it
@ajayrgb @jayanthshimoga I have just created a PR which addresses and hopefully fixes the issue. Let me know if it works once it is merged and released via nightly (v0.11*)
the latest nightly should have the fix, feel free to reopen the issue if it still persists
Confirmed working in 0.11.0a6
. Thank you for the quick fix!
Confirmed working in
0.11.0a6
. Thank you for the quick fix!
Hey Tested this with the latest version 0.11 and issue appears to be still there. We tested this with Jupyterlab 4.2.2
We utilize JupyterLab 4.1.6 in our organization for several users.
Each Jupyterlab instance creates a separate pod in the Kubernetes cluster. We have a poetry repository where we handle all of the requirements, and jupyterlab-nvdashboard is version 0.10.0. When we tried the machine resources in the GPU area, we didn't obtain any graphs because the overall URL was abstract rather than user-level.
So we adjusted the code accordingly and tried monkey patching by modifying the handler.ts file to below code. Place where we updated code :https://github.com/rapidsai/jupyterlab-nvdashboard/blob/branch-0.11/src/handler.ts#L7C1-L9C61
When we run
wscat -c "wss://<domain>/user/jayanth/nvdashboard/cpu_resource
in jupyterlab, we can see the results, but the graphs are not rendering properly. The graph only works for CPU UTILIZATION and not for MEMORY USAGE, DISK IO BANDWIDTH, or NETWORK IO BANDWIDTH.