-
Notifications
You must be signed in to change notification settings - Fork 223
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow enterprise gateway to launch k8s kernels on remote clusters #1235
Comments
Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗 |
This sounds really interesting. So a given EG server would still target exactly one Kubernetes cluster in which the kernels are launched - these changes simply enable the ability for that cluster to be remote. Is that correct? You'll also need to take into account the possibility of the user having configured the At any rate, those are implementation details that we can work out. We look forward to your pull request. (Just a note that changes within the Process Proxies functionality, will be dropped in our EG 4.0 release in favor of using the kernel provisioner framework that is now part of the general Jupyter stack, so it would be great if you can participate in the Gateway Provisioners project. I'm (frantically) trying to get things in place for a release over there as we speak. If you're unable to make applicable changes, no worries, we'll port them over at some point closer to making the switch. I just wanted to make you aware of that future transition.) |
Yup! That would be exactly correct. Thanks for reminding me about the shared namespace option! That's something I forgot to consider, I'll also look through the other k8s options to ensure we don't raise a conflict. In regards to the new gateway provisioners, thanks for making me aware of that as well. I'll take a look there for the effort to port over the new k8s client pattern w remote cluster and let you know. |
You should find things nearly identical with the exception of name changes and the fact that there isn't a hosting application in the repo. I need to apologize for the existing documentation (still converting from EG), tests (that are nearly zero), and lack of an installable package (hopefully soon), so bear with us. |
Is there an issue or PR that tracks the effort to let EG use the Provisioners? |
Yes - you opened #1208. 😄 |
It would be useful if one could also point to a specific kube context for a given kernel |
Problem
Proposed Solution
Therefore the code changes are as follows
This also has an added benefit of replacing the use of static clients with an atomic export, so configurations are consistent.
Willing to start working on this if there's no opposition!
The text was updated successfully, but these errors were encountered: