dynamic kernel whitelist #1059
-
|
Hi, I'm wondering about the possibility of dynamically updating the kernels offered by Enterprise Gateway. For example, the Gateway is running in docker with the kernelspecs directory mounted so it can be accessed from outside the container. If I were to place a new kernel (and kernelspec) there, how can I tell the Gateway that there is a new kernel offering, and is it possible to update without restarting the gateway? I know this env var sets the kernel whitelist and dynamic configuration is supported for some configs but I was unable to confirm that it works for the kernel whitelist. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
Hi @bloomsa - thank you for opening this discussion. To get this behavior, you could simply remove the whitelist env altogether. By default, new (updated, and deleted) kernelspecs are detected as soon as the next request comes in for them (which I believe tends to be too frequent, but, in this case, is a good thing). If you wanted to tie this to dynamic configuration you'd need to configure the whitelist via the configuration file which, in container worlds, is also not that helpful. Command-line and env-based values always override the file-based configurables and, therefore, are not privy to dynamic configuration (which is caveat #1). |
Beta Was this translation helpful? Give feedback.
-
|
wonderful, thank you for the quick reply! I tried setting the env variable as [‘*’] but not leaving it out entirely. The dynamic config piece of the answer makes sense too. thanks again 🙌 |
Beta Was this translation helpful? Give feedback.
-
|
For completeness, it turns out the capability discussed here was not practically available for containerized environments until #1131. |
Beta Was this translation helpful? Give feedback.
Hi @bloomsa - thank you for opening this discussion. To get this behavior, you could simply remove the whitelist env altogether. By default, new (updated, and deleted) kernelspecs are detected as soon as the next request comes in for them (which I believe tends to be too frequent, but, in this case, is a good thing).
If you wanted to tie this to dynamic configuration you'd need to configure the whitelist via the configuration file which, in container worlds, is also not that helpful. Command-line and env-based values always override the file-based configurables and, therefore, are not privy to dynamic configuration (which is caveat #1).