Add compatibility prompt and notes for shared group mounting

[viniciusdc]

Reference Issues or PRs

closes #2736

What does this implement/fix?

Put a x in the boxes that apply

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds a feature)
• Breaking change (fix or feature that would cause existing features not to work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build related changes
• Other (please describe):

Testing

• Did you test the pull request locally?
• Did you add new tests?

How to test this PR?

Any other comments?

[viniciusdc]

Tested locally:

From a fresh deployment

inspecting the keycloak UI we can assert the role is now present there

Using a custom role created from the UI:

[viniciusdc]

For the failling tests, I think the our keycloak module when imported ends up initializing a connection by default with the keycloak server, which leads to issues. Will address these soon

[viniciusdc]

For the failling tests, I think the our keycloak module when imported ends up initializing a connection by default with the keycloak server, which leads to issues. Will address these soon

I found the root issue. In the affected tests, we have a whitelist of prompt messages and their expected responses. If the prompt is not added there, it defaults to yes. That's why it skipped my default N value in the upgrade step and reached out to the keycloak endpoint.

[kenafoster]

I think this could use a little more detail explaining exactly what's going on here and specifying that the two options here are either all groups or just admin/analyst/developer. Suggested rewording below (please review for accuracy as well as grammar!)

Nebari version [green]2024.9.1[/green] introduces changes to how group directories are mounted in JupyterLab pods.

In previous versions of Nebari, every Keycloak group in the Nebari realm initiated the creation of a shared file directory that all group members could access in their JupyterLab pod at ~/shared/[group-name].

As of Nebari version [green]2024.9.1[/green], only groups that are assigned the jupyterhub Client Role allow-group-directory-creation will

You will be asked to confirm whether Nebari should now assign this role to all of your current groups. If not, only the admin, analyst, and developer group directories will be mounted in JupyterHub pods.

Regardless of your choice now, no data will be lost during this operation. You can re-mount group directories at any time by adding or removing the allow-group-directory-creation-role from your groups in the Keycloak UI.

For more information, please see the [green][link=https://www.nebari.dev/docs/how-tos/group-directory-creation]documentation[/link][/green].

[kenafoster]

If we are clear with what the feature is actually doing in the intro text, then I think we can change this to:

Would you like Nebari to assign allow-group-directory-creation-role to all of your groups now?

[viniciusdc]