kubespawner
kubespawner copied to clipboard
Add image data to state exposed via API
Looking at #2598 over at JH, it would be beneficial to add more runtime data to the data exposed through the API to allow for more flexible services.
Right now, this only adds the image data to the state dict. I'm wary of the implications of loading that field and overriding configuration since I'm not as familiar with how that will affect the spawner process. If it's not going to break anything, that can be added as well.
Still need to check if it even records valid data in combination with profile_list and options_form overrides.
Update: Looks to work fine w/ options_form and profile_list overrides.
It also appears that Kubespawner already exposes the selected profile name under user_options in the JH db. Perhaps the /users API endpoint should be corrected to return that data instead. Opinions? The selected profile name may be a better, more flexible choice as it's going to be independent from the actual image (and tag).
@minrk @rkdarst --- can I get your help to review this PR?
This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there:
https://discourse.jupyter.org/t/binder-jupyterhub-activity-round-up-week-1/2704/1
I find this hard to review, it is a one liner about something I lack the overview to figure out well, help to review this wanted!
To be fair, I'm even mixed on this PR. The driver behind this is really that there's no way to provide a smarter culler service that can alter time limits based on containers or container properties. Placing the image name in the saved state data exposes it via JH's API for others to act upon. JH issue here: https://github.com/jupyterhub/jupyterhub/issues/2598
We appear to already store the user's selected options_form entry, but it goes into a separate dictionary that is not exposed by the API for whatever reason. A discussion on adding that data to what is exposed via the API didn't really go anywhere. There were concerns over the sensitivity of the data, but the data is only accessible to administrators so it's moot in my opinion.
I suggested moving the culler service internally where it can access everything it could possibly need without duplicate (and therefore brittle) secondary configuration and submitted a POC but we didn't go in that direction, leaving us without a solution or route to one. https://github.com/jupyterhub/jupyterhub/pull/2664
Adding this to the state data is a step towards something configurable to achieve container-based time limits, but I will admit that this does not personally feel like the best solution, as the image name is going to be big and noisy wrt tags and versions and whatnot.
I'm sorry for not helping this PR resolve faster, I think maybe a strategy to accomplish something like this can be do use a hook (pre_spawn_hook?) to update the user authentication state in any way based on the the spawner state.
I'll go for a close here, since its a very old PR thats a one-liner change as well.
https://github.com/jupyterhub/jupyterhub/issues/4406 is kinda a more generalized ask of this category of problems I think.