[BUG] - shared mount files not showing up on recent upgrade for 2024.9.1rc3

[viniciusdc]

Describe the bug

After the changes in #2593, a small bug was introduced concerning how the shared volume mount was being handled. Instead of mounting to /shared/<group_name>, an extra slash delimiter was unintentionally added due to a bug in one of the Keycloak to JupyterHub sections of the code.

This led to new subpaths being included in the pod specifications as /shared//<group_name>. For newer deployments, this issue was not apparent and was difficult to catch unless inspecting the pod's YAML specification directly, since the subpaths and symlinks were generated correctly—albeit pointing to a double-slash folder location.

However, the problem arises in existing deployments because the symlinks would have been broken. The volume mounts were not correctly mounted since those subpaths did not exist, which would most likely generate conflicting data.

Bellow you can see a comparassion of a upsgraded cluster and a fresly created one:

Here due to an issue with the setings in the volumeMoutns, the vlume was not created and thus the expected shared link was not correcly binding in the user jupyterlab container as seen below:

Here you can see the fresly instanciated EFSs from a new cluster do accept the double slashing, albeit this is wrong.

Expected behavior

shared folder should exist and contain the required user groups on upgraded nebari clusters

OS and architecture in which you are running Nebari

Linux

How to Reproduce the problem?

upgrade an existing nebari deployment to 2024.9.1rc* release

Command output

No response

Versions and dependencies used.

No response

Compute environment

None

Integrations

No response

Anything else?

No response

[viniciusdc]

The associated fixing PR addresses the broken link and incorrect subPath in the pod volumes specification. Still, it does not address the user facing issue after spinning up the cluster (after the upgrade), as seen in the image below:

After the upgrade, the user with a logged-in session will have an issue with his /their shared folder. This is because the user_data is "cached" internally, resulting in the required metadata for the group mounting not showing up in the lab's spawning process.

There's nothing we can do except log in and login again to update the data.... every user will need to do that. I wonder if this could be added as part of the upgrade command as an option to the user as well #2739