Service discovery of APIs running in tooling containers of Workspace.Next

[garagatyi]

Description

In Workspace.Next we have an ability to launch a server (API) in a sidecar container and then access it from another container. For example Theia. This is the case we have with Language servers in Workspace.Next. Even though we can start a LS as a sidecar it is not obvious how Theia LSP client would connect to this LS.
So we should find a way how to address that in Workspace Next.

Options:

1. Expose LS port as Che Workspace Server and let a client (e.g. Theia) access Che Workspace API to get links (Thanks Sergii for suggesting this option).
2. Provide an idea how we will do a service discovery in Workspace.Next, so Feature author can hardcode some predictable link to a sidecar in his plugin.
   Example: I configure Java support in Theia by adding JDT.LS as a sidecar and Java assist plugin in Theia. Java assist plugin in Theia may expect to access JDT.LS socket by address feature-java-jdtls:3610 or fetch an environment variable with some known name which would contain link to that socket.

[garagatyi]

cc @l0rd @skabashnyuk @tsmaeder @gorkem @slemeur @benoitf @ashumilova

[garagatyi]

@tsmaeder @gorkem @slemeur @l0rd WDYT about option 1 where we don't have any particular service discovery mechanism, but have to have Che specific code that can find needed URLs from Che Workspace API suggested by Sergii? This is much simpler and we can start from that right now. On the other hand it require Che specific code in each component(plugin) that wants having a sidecar agent which might not be very good for community of Theia plugin developers.

[ghost]

@garagatyi btw, some Che Theia plugins already rely on a workspace API extension and env variables in Theia, so that they can grab ws-id, call workspace API and get links from runtime. So, this isn't new.

But it's a good question - whether or not we need to have Che specific code in those plugins. In other words, do we need to make those plugins run in a standalone Theia?

On the other hand, we will need to extend LS client in Theia anyway to make it connect over host:port rather than launch a process and communicate over stdio.

[gorkem]

I think we can get best of both worlds. We already had a conversation about modifying the LS client on Theia to read connection parameters from environment variables. Theia client would read the environment variable and connect with those parameters otherwise fallback to local connection. This mechanism will be invisible to the LS and not specific to Che.

So far we have assumed that those parameters are passed as part of the pod description, however we can add an extension to Theia that would read these parameters and update the environment variables on the node.js instance that is running the IDE (nodejs env. variables can be updated unlike Java).

[ghost]

@gorkem good point. So, ideally, if smth grabs $ls_service_name:$ls_port from LS service description and throws it into the IDE pod with Theia as an environment variable, Theia LS client can then make decisions accordingly?

Question: do we need internal endpoints (service:port) or external ones (routes) in this particular case? Will these two containers be part of one pod? Or two different pods?

[garagatyi]

So, ideally, if smth grabs $ls_service_name:$ls_port from LS service description and throws it into the IDE pod with Theia as an environment variable, Theia LS client can then make decisions accordingly?

I think that the case is a bit different. Since we can't use a plugin to set env vars in a pod. In my mind the use case is:
We add a Che-specific plugin that reads server links from Workspace API and updates nodejs env accordingly. So we don't need any service discovery mechanism.
In this case we always depend on reading env vars by Theia, but we can have several ways to set those env vars.

Question: do we need internal endpoints (service:port) or external ones (routes) in this particular case? Will these two containers be part of one pod? Or two different pods?

For the time being we expect all the tools be in a single pod. It might change since one of the goals of Workspace.Next is development of multiple microservices of an application. But sharing a volume might not be possible (or viable for dev purposes) in multi-cluster environment, so this would be tricky and we are trying to implement single pod for now.
It's a good question whether we need here internal or external endpoints. For the LS it makes sense to use internal endoint, but there might be other cases.

Even though we have a CheService object in Workspace.Next model we agreed that those are just names that don't have to have anything common with k8s or OS terminology. Should we use these for service discovery? Not sure. Right now they are using dots in names and it will be tricky to use such names for service discovery.
Since we already have a concept of server it would be nice to reuse it somehow in service discovery.

But it really seems that we don't need service discovery if we use the idea by Gorkem. It will require implementing a plugin in Theia, but much easier for infrastructure since doesn't require any particular discovery implementation.

[ghost]

@garagatyi there's a Theia plugin that can talk to workspace API. I think the point that Gorkem and Thomas are trying to make is that in this case, LS client in Theia won't be universal, and will work only when Theia is a part of a Che workspace.

Otherwise, the approach is clear enough.

[gorkem]

LS Client will be universal because it expects the connection properties on the environment variables. I am suggesting a Theia extension that reads those values and feeds them into process.env

[garagatyi]

Small clarification. It is supposed that this issue target only kubernetes/OS infras.