Open jgwright-eitccorp opened 1 year ago
Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.
You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:
I call the private method for this reason. I do conditional pvc provisioning in my hooks. +1
KubeSpawner has a modify_pod_hook
that's called between making the manifest and applying it
https://github.com/jupyterhub/kubespawner/blob/dbacf2b8a1f135d810478b5d605e0a8370c0ac90/kubespawner/spawner.py#L973-L993
https://github.com/jupyterhub/kubespawner/blob/dbacf2b8a1f135d810478b5d605e0a8370c0ac90/kubespawner/spawner.py#L2679-L2690
Would something similar for PVCs cover your requirements?
@manics Having a modify_pod_hook
method probably could work for all intents and purposes. The only thing that nags at me about that approach is that, given some of the things we'd be doing in that method, it might make the logic _make_create_pvc_request
totally extraneous (i.e. the call to create a namespaced PVC that we've already determined exists and have patched).
I'm also interested in this as I'm trying to figure out how to dynamically provide two storage areas per user, one fast and small disk based for the home and virtual environments and one smb-based for larger data sets with big files. My initial plan was to hack something into pre_spawn_hook, but I'm happy to contribute to a more generic solution.
Proposed change
We would like a publicly exposed extension point on
KubeSpawner
for overriding the user pod PVC provisioning logic that is currently encapsulated by the privately scoped_make_create_pvc_request
method. We have some very specific requirements for provisioning of user pods that include:Ideally, this could be exposed by refactoring
_make_create_pvc_request
to a publicly scoped method named along the lines ofprovision_user_pvc
ormake_user_pvc_request
, with the default implementation being the current logic.Alternative options
We could implement some or all of the above logic:
get_pvc_manifest
, but that feels wrong, given that the purpose of that method is to create the PVC manifest from the provided settings_make_create_pvc_request
, but that breaks encapsulation by conventionWho would use this feature?
Anyone deploying ZTJH where there is a need for a custom user PVC lifecycle or rules for provisioning a user PVC that is not covered by the default use case.