profile_list AND free values/text?

[h4gen]

Hi! I really like the profile list as it provides a convenient way to provide static settings. On the other hand it takes away the possibility for the user to pass non-static options to the starting pod. In my case I would like to keep the list but also give the user the ability to enter text to configure his pod. For example a text field with a certain image to be used on the pod. With the current solution the admin has to introduce this image. This is blocking the admin as well as the user. Is there a way to keep the profile_list but also get options as in the reference example?

[consideRatio]

You could override the spawners pre_spawn_hook and adjust the options of profile_list based on the user. That way you would get a user dependent list of predefined options. But, I don't know how to achieve a way to let the user dictate options freely.

An overview

• a single fixed option (default)
• a list of fixed options (set profile_list once)
• a user dependent list of fixed options (set profile_list from the pre_spawn_hook)
• one or more user dynamic options (set options_form once)
• one or more user dynamic options, with some preset options (profile_list + options_form ... don't work, right?)

---

Question raised

• Is kubespawner's profile_list utilizing options_form behind the scene?
• (off topic) Is there a reason for profile_list to reside in kubespawner rather than within the base Spawner class?

[h4gen]

@consideRatio Yes, the overview sums it up pretty good. Using the pre_spawn_hook is what I currently do to use a specific image per user. So the users are free to enrich their environment with a Dockerfile which extends a base image and pushing it to their repo. This is already a good solution but not perfect. Being able to provide a free text while keeping the profile_list (e.g. for resource settings) would give the users way more possibilities to customize their environments (e.g. containers for different user projects). Currently they are mutually exclusive.

[consideRatio]

#317 and this are almost the same request.

[yuvipanda]

I believe this would be fixed by #735

[yuvipanda]

This has been implemented by #735