Override EG_RESPONSE_IP and EG_RESPONSE_PORT via kernelspec?

Kernels Enterprise Gateway
1

Hi,

We have a Enterprise Gateway pod running on Kubernetes that we want to use to spawn kernels in the same K8s cluster as EG and in remote locations via proxy. Is it possible via kernelspec to override the EG_RESPONSE_IP and EG_RESPONSE_PORT values so that when it is a local kernel it can use the pod IP or the internal IP and defaul port (8877) and when it is a kernelspec belonging to a remote kernel location, use a different IP (the k8s node IP and nodePort port)

Thanks,
Debashis

2

Hi @debashis1982 - thank you for your question.

There is no ability to override EG_RESPONSE_IP and EG_RESPONSE_PORT on a per-kernel basis. These values point at the ResponseManager (which is a singleton) within the EG process.

and when it is a kernelspec belonging to a remote kernel location, use a different IP (the k8s node IP and nodePort port)

I’m curious about your use case. These environment variables are used during the kernel pod launch and indicate where the kernel should be sending its connection information, namely, the launching EG server. Are you suggesting the ability to launch kernels from one EG instance, but expect their lifecycles to be managed by a different EG instance (and one that did not launch those kernels in the first place)?

3

Hi @kevin-bates
Our EG instance running on kubernetes is expected to launch some kernels in the same kubernetes cluster EG is running on and also be able to launch other kernels in an external location via a remote kernel launcher (using RemoteProcessProxy)

Thanks,
Debashis

4

Hi @debashis1982,

Only one value for the response IP and port can be configured and those values must reflect the location of EG instance that launches the remote kernel since that instance (via the configured process proxy) is responsible for managing the kernel pod’s lifecycle.

That said, you might be interested in this recently posted pull request in which it provides the ability for EG to reside in one Kubernetes cluster, but have all of its kernel pods launched into a separate (external) Kubernetes cluster (i.e., kernel pods only reside in the external K8s cluster). But even here the (external) pods are managed by the launching EG instance (located at EG_RESPONSE_IP:EG_RESPONSE_PORT).

With this PR, there might be an opportunity to support both k8s clusters simultaneously where a hint as to which k8s client to interact with could be provided in the kernel’s specification (kernel.json) file. But again, there’s still a single EG instance managing the kernel pod lifecycles, irrespective of those pods’ locations.

Thanks,
Kevin.