Refactor role creation for upgrade command path

[viniciusdc]

Reference Issues or PRs

closes #2766

What does this implement/fix?

This issue is a patching fix for the upgrade command present in the previous release, currently the upgrade logic when requesting the user to perform the role creation (more details see linked issue), assumes the presence of the role when assigning it to the legacy groups. However, this leads to errors when the role does not exist or is within Terraform if the user attempts to manually address the missing role to continue the upgrade.

This PRs includes a new section in the previous code logic to create the role, and to avoid conflicts with terraform, I adopted a "legacy" prefix to the role name with a befitting description for future reference when the amdins manages keycloak in the future.

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?

• Perform any type of deployment for Nebari v2024.7.1, local is advised,
• create some testing groups and users with such users assigned to some of these groups (one user and one group should suffice).
• Launch one user instance and assert the folders are mounted;
• Install this nebari version in dev mode and perform the upgrade; (You will need to create a tag locally for proper installation of nebari)
• Assert the new role has been created in the jupyterhub client, and the previous groups all have the role assignment;
• Perform the deployment and launch a user instance to validate the folder mounting is kept the same (consider logging out first to avoid issues with caching of user_Data)

Any other comments?

[viniciusdc]

There are no tests for this yet, and I would like to have this tested to help us avoid this situation in the future. I hope we get #2780 merged before this to extend the testing suit.

[viniciusdc]

I will be testing this during the afternoon

[dcmcand]

Let's disable the 2024.9.1 upgrade step as part of this @viniciusdc

[viniciusdc]

It was tested on a local deployment, moving from 2024.7.1 directly to 2024.9.2 (will need to test again since this now changed to 2024.11.1):

• Group created on the previous version:
  
• After upgrade command:
  • legacy role is included to existing groups:
    
  • after deployment, both roles now exist (no terraform conflict)
    
  • previous behavior of mounted groups folders is preserved
    

[viniciusdc]

This needs to be re-tested to ensure the upgrade will run now that we moved it to 2024.11.1

[viniciusdc]

Re-tested with the recent changes:

[marcelovilla]

LGTM! 🚀

[viniciusdc]

These tests are failing only for DO, and it might be related to its decommissioning process. So, we can disregard it for now, I've created a separated issue for this so that it does not become a blocker #2810

[dcmcand]

🚀

Thanks for this @viniciusdc