You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use the synchronous kubernetes client. Since kubespawner is tornado based, we need to make it work asynchronously. So we use threadpools. However, threads are hard! Async is hard! Mixing those two, as much as we do here, is hard! Forming a complete mental model of how the different threadpools in the application interact with each other to affect throughput is extremely hard - see #419 for example.
I suggest we move the k8s calls to kubernetes_asyncio. dask-kubernetes started with this from the beginning, and it's been a great experience. It's generated in exactly the same way the upstream synchronous client is generated, so maintenance & new features have been good. More context in [https://github.com/kubernetes-client/python/issues/323](this issue)
Alternative options
Keep using the current library, but develop a better understanding of threadpool interactions
Build on top of kube-rs. The big advantage here is that it's got fairly complete implementations of higher level kubernetes primitives like watchers & controllers. We implement them ourselves in python, but I'm not sure how thorough they are. However, as a downside, it's in Rust and will need effort to integrate into our codebase.
Who would use this feature?
Developers who are working with the codebase. Threading is hard.
Users who want higher throughput.
(Optional): Suggest a solution
I think we have enough tests here and in z2jh to be able to do this. The syntax is pretty compatible, so it would be a matter of going through the code base and making changes.
The text was updated successfully, but these errors were encountered:
Proposed change
We currently use the synchronous kubernetes client. Since kubespawner is tornado based, we need to make it work asynchronously. So we use threadpools. However, threads are hard! Async is hard! Mixing those two, as much as we do here, is hard! Forming a complete mental model of how the different threadpools in the application interact with each other to affect throughput is extremely hard - see #419 for example.
I suggest we move the k8s calls to kubernetes_asyncio. dask-kubernetes started with this from the beginning, and it's been a great experience. It's generated in exactly the same way the upstream synchronous client is generated, so maintenance & new features have been good. More context in [https://github.com/kubernetes-client/python/issues/323](this issue)
Alternative options
Who would use this feature?
(Optional): Suggest a solution
I think we have enough tests here and in z2jh to be able to do this. The syntax is pretty compatible, so it would be a matter of going through the code base and making changes.
The text was updated successfully, but these errors were encountered: