Expose PVC Provisioning Method

[jgwright-eitccorp]

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:

• Detect when the size of the PVC requested is larger than the currently allocated PVC, and issue a "Patch Status" request to increase the capacity (which for EBS CSI volumes, should trigger an expansion of the volume)
• Detect that a user's volume has been archived and deleted, and trigger a re-constitution of the user's EBS volume before re-creating the PV/PVC

Ideally, this could be exposed by refactoring _make_create_pvc_request to a publicly scoped method named along the lines of provision_user_pvc or make_user_pvc_request, with the default implementation being the current logic.

Alternative options

We could implement some or all of the above logic:

• By overriding get_pvc_manifest, but that feels wrong, given that the purpose of that method is to create the PVC manifest from the provided settings
• By overriding _make_create_pvc_request, but that breaks encapsulation by convention

Who 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.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

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! 👋

Welcome to the Jupyter community! 🎉

[jabbera]

I call the private method for this reason. I do conditional pvc provisioning in my hooks. +1

[manics]

KubeSpawner has a modify_pod_hook that's called between making the manifest and applying it

kubespawner/kubespawner/spawner.py

Lines 973 to 993 in dbacf2b

	modify_pod_hook = Callable(
	None,
	allow_none=True,
	config=True,
	help="""
	Callable to augment the Pod object before launching.
	Expects a callable that takes two parameters:
	1. The spawner object that is doing the spawning
	2. The Pod object that is to be launched
	You should modify the Pod object and return it.
	This can be a coroutine if necessary. When set to none, no augmenting is done.
	This is very useful if you want to modify the pod being launched dynamically.
	Note that the spawner object can change between versions of KubeSpawner and JupyterHub,
	so be careful relying on this!
	""",
	)

kubespawner/kubespawner/spawner.py

Lines 2679 to 2690 in dbacf2b

	pod = await self.get_pod_manifest()
	if self.modify_pod_hook:
	self.log.info('Pod is being modified via modify_pod_hook')
	pod = await maybe_future(self.modify_pod_hook(self, pod))
	ref_key = f"{self.namespace}/{self.pod_name}"
	# If there's a timeout, just let it propagate
	await exponential_backoff(
	partial(self._make_create_pod_request, pod, self.k8s_api_request_timeout),
	f'Could not create pod {ref_key}',
	timeout=self.k8s_api_request_retry_timeout,
	)

Would something similar for PVCs cover your requirements?

[jgwright-eitccorp]

@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).

[dragz]

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.