Enable `unlisted_choice` for all staging hubs using a profile list overriding the user image

[GeorgianaElena]

Context

Hubs using a profile list cannot quickly test a new image tag using the configurator. Instead, community reps need to request an update to the image and tag via a support ticket that we then implement and merge.

Ref https://github.com/2i2c-org/infrastructure/issues/2874

Proposal

We could enable unlisted_choice on staging hubs that have profile lists (edit: with kubespawner_override.image) to mitigate this friction and document this as the recommended way to test a new image before making it available on prod hubs.

Updates and actions

This has already been deployed to openscapes staging hub https://github.com/2i2c-org/infrastructure/issues/3079

[consideRatio]

I think we are forced to duplicate and non-trivially adjust the profileList for each staging hub if we do this, and that makes me hesitate. I think that it is probably better than not having a way for community's to test new images though.

I support this proposal until there is a known better option.

There are some situations to consider for clarify

• should we add entirely new profileList entries, or should we update one or all existing entries?
• if updating an existing entry, i think the right call is to:
  • in case of an "image" profile_options entry is provided, add unlisted_choice to that option
  • in case of an "image profile_options entry isn't provided, we define one and let the default choice be the one otherwise part of the profile itself, and then we add unlisted_choice

I support the proposal, where the procedure should be to: ensure the staging hubs profile list entries overriding image always has a profile_options entry to specify the image with unlisted_choice enabled.

[GeorgianaElena]

I think that it is probably better than not having a way for community's to test new images though.

I agree with this line! I will nominate it for this quarter's work if you are ok with it @consideRatio