-
Notifications
You must be signed in to change notification settings - Fork 222
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
Custom resource configuration #640
Comments
No, nothing in the works yet. Where this is heading is parameterized kernels (or kernelspecs more like in my opinion) - which has been floated in the community as something many would like. Today, this is accomplished (only in EG to my knowledge) via envs. However, in order to break from of the NxM issue (where N is things like small, medium and large and M is the set of kernels), we pretty much need to ask for the parameters when the kernel is launched. This can be accomplished via a nb/lab extension. Then, this could gather the parameters and convey them to the parameterized kernelspec. For k8s, the kernel-pod jinja template could then include a Ultimately, I think we'd want a more formal section in the kernel request body, say something like {
"language": "python",
"display_name": "Python on Kubernetes",
"metadata": {
"process_proxy": {
"class_name": "enterprise_gateway.services.processproxies.k8s.KubernetesProcessProxy",
"config": {
"image_name": "elyra/kernel-py:VERSION"
}
},
"parameters": {
"cpus": { "min": "0.5", "max": "16", "default": "2"},
"memory": { "min": "1GB", "max": "32GB", "default": "4GB"}
}
},
...
} Then, once prompted for, the kernel creation request would have a stanza like... {
"parameters": { "cpus": "8", "memory": "8GB"},
"env": { ... }
} The other thing is that the environment might dictate how this is accomplished as well. For example, containerized envs would probably have different sets of parameters than say a YARN/Spark environment and their means of getting them conveyed to those respective environments will vary as well. |
Impressed. It sounds like this would be good to start for EG, right?
After EG supports it first, if notebook env (extension) supports to send request with |
Hi Folks, we have been thinking to introduce json schema in render_ui_from_schema.mov
Kernel.json metadata field will contain the data corresponding to schema. Note- Schemas are totally independent. Each enterprise can have their own schema defined. UI plugin will read the schema from getkernelspec schema API and render the content from kernel metadata field. |
Hi @nsingl00 - thanks for commenting on this issue. I absolutely agree that kernel parameterization, and, per this issue, custom resource configuration, should/must be schema driven and, yes, that schema (or reference to a schema) must reside within the I also strongly believe that the parameterization/customization associated with a kernelspec must be derived from the kernel provisioner associated with that kernelspec. As your example so clearly illustrates, most parameters will not be directly associated to the kernel itself, but, rather, to the environment in which the kernel runs - which is the precise responsibility of the kernel provisioner. However, both the kernel and the kernel-provisioner should be asked to provide their respective schemas since we simply cannot ask users to create these from "whole cloth" - which can be easily done by the I would really prefer to keep the schema used to render UI separate from the schema used to describe kernel/provisioner parameters and view the UI schema as orthogonal and, frankly, the purview of the application that needs to render the parameter selection in a usable manner. There is a current JEP regarding parameterization that I personally feel falls short as it does not include the provisioner's involvement (see my comments). I had authored a previous JEP, which I retracted due to lack of input, although it seems traction for schema-based parameterization has picked up recently. Unfortunately, I don't believe your comment will get much traction here and would encourage you to read over the various linked proposals and get involved on the current JEP or in either Also note there has been a wave of "schema persistence" discussions that, yeah, I could see a kernel provisioner (and a kernel) posting their schemas or, generally making their schemas, available to a "schema service" or repository. @Zsailer (hi Zach! 😄) can point you to the schema-related discussions. Lastly, I think it makes sense to close this issue. Yes, EG (or Gateway Provisioners more likely) will adopt whatever parameterization approach is set forth by Jupyter Server. If you'd like to continue this conversation here, I'm fine with that also. |
In project roadmap,
I'm resolving this in k8s env by adding new kernelspec (e.g. small-tensorflow, medium-tensorflow, ...) and modifying
kernel-pod.yaml
(e.g. setting resource request and limit).However, every time I add a new kernel, then kernelspecs including all resource-configuration (small, medium, large) should be added to the system. This makes our system too verbose and HW spec is too coupled with SW spec.
Is there any in-progress item for this? Any idea will be welcome. I need your help!
The text was updated successfully, but these errors were encountered: