Hybrid Runtime Support

[psychemedia]

Hi

The overview.html#hybrid-runtime-support docs seem to imply that a user with a local notebook server can connect to a remote kernel using elyra, but I've not been able to track down any examples of how a user would go about this?

Ideally, if this is possible, there would be documentation that helps a user connect to a remote kernel server / gateway set-up to allow external connections (what does the user need to know about that server/gateway? What config setting do they need to make where on their local setup to add the remote kernel as an option on their local notebook server kernel list);

It would also be useful if there was a link to docs for enterprise / remote gateway admins telling them what they need to do to allow remote connections (and where they should point their users for advice on what the users need to do (this could be a link to the users docs identified above)).

Thirdly, I could imagine there might be a different set of things to do for JupyterHub admins who want to be able to set up JuptyerHub services running elyra where the JupyterHub users get to select kernels that are running locally on the JupyterHub server, launched on a hub manages k8s cluster, or connected to remotely via a remote gateway elsewhere.

I guess there's also all manner of things that need to be handled by gateway and hub admins, as well as local users, in order to manage authentication and proxies?

[ptitzler]

@kevin-bates @lresende?

[kevin-bates]

Hi @psychemedia. We do have some docs that touch on Elyra deployments with Jupyter Hub and Enterprise Gateway but, honestly speaking, it is only usable for local pipeline processing which, itself, is limited.

I know that @lresende did set up such a configuration (Hub + EG) - probably to draft the docs. I have set up an Elyra/EG configuration (sans Hub), but that's really no different than Notebook/EG leveraging the --gateway-url.

[psychemedia]

Ah, okay... I guess I was reading too much into "Elyra contributes a Script editor with support for Python and R files, which can take advantage of the Hybrid Runtime Support enabling users to locally edit scripts and execute them against local or cloud-based resources seamlessly."

I was imaging the ability of a user with a local notebook server being able to install a means of launching and connecting to a remote server via their kernel selection list.

In general, this would open up the ability for users to run local services for all their lightweight tasks (and without the need for a network connection) and only connect to a remote kernel if they need to access eg a powerful GPU environment.

Currently, the only way I know how to do this off-the-top-of-my-head is a two stop process of manually accessing into remote Jupyer server environment to get the connection string (and a token) and then connecting to it in VS Code using the the Jupyter extension remote kernel connection (which is a route that has worked since the VS Code Python extension first supported notebook server kernel connections).

[kevin-bates]

I guess I was reading too much into "Elyra contributes a Script editor with support for Python and R files, which can take advantage of the Hybrid Runtime Support enabling users to locally edit scripts and execute them against local or cloud-based resources seamlessly."

Yeah, not so sure about the use of seamlessly there.

Today, when a notebook server is configured with Enterprise Gateway, all kernels come from the gateway server. There really isn't a way to have some kernels local to the notebook server and others served remote (including remote from EG) from the EG server. It's an all-or-nothing thing.

With Kernel Provisioning, we can support both local and remote kernels simultaneously. A good example would be a Kubernetes-hosted notebook server with a kernel provisioner that supports launching the kernel in a separate Kubernetes pod within the same k8s cluster. In this case, the LocalProvisioner (which exists out-of-the-box) could execute a kernel within the notebook server pod, while a Kubernetes-aware provisioner could execute a kernel in its own pod.

You could probably bypass the same-cluster issue by creating a provisioner that essentially interacts with a gateway server and uses the gateway server as a bridge into the remote cluster.

[lresende]

So, what you can do today is:

• Start a notebook server locally and use local resources in a disconnected fashion

• Start a notebook server locally and connect to a remote Enterprise Gateway via the --gateway-url.

  • This would enable you to use resources from the remote server (e.g. GPUs, large resources, etc)
  • I believe you could also have a local kernel, that would give you access to local resources

• And off course, use it as a self-service using hub (with or without EG)

Now, what we don't have is the ability to connect to a remote EG on a per-kernel basis, which would enable you to stay disconnected until the moment you need access to additional resources. That is what we would need to support your use case without having to shut down the server and restart the server pointing to a EG server.

NOT A CONTRIBUTION

[psychemedia]

Okay, thanks... On reflection, I guess I hadn't thought this through at all and was subsuming kernel start against an already running server, with a kernel launch that is actually a server start request and then a kernel start.

For my own use case (making remote kernels available to students) I think I may need to think more along the lines of working with "remote kernels" (eg as per JoostJM/remote_kernel), although that does then incur the overhead of enabling ssh on the remote server.