Theia Plugin Broker

[garagatyi]

Description

We need a plugin broker that would be simpler than current Che plugin broker and deliver only Theia specific plugins into a workspace. This task would include the way to configure a custom plugin broker (in a sidecar definition?) and implementing the broker.
It would simplify the packaging of a Che plugin that contains only a Theia plugin.

Broker
For each type of plug-in hosted on plug-in registry, a broker is called.
Broker is a docker container accepting a specific type of plug-ins (like Che plug-in, etc) and returning a set of

• Endpoints
• Containers
• Editors

For example, it can extract metadata from a plug-in, grab the link of a plug-in, download the file and copy it over a mounted folder.
A broker is pluggable.
Theia can come with its own broker: it would avoid to package .theia plug-ins inside che plug-ins. This broker would wrap automatically .theia files with the associated theia editor

JDT.LS could also provide its own broker for copying for example all jdt.ls addons to a directory like /jdt.ls.addons

Theia plug-ins inside of Che.

background
Theia is running by default all extensions and plug-ins on the same host.
It means that if a plug-in foo requires the foo tool, this tool needs to be installed on the host.
For example if a plug-in might want to compile a .java file, then javac should be there.
A plug-in can be run on the browser side or on the backend side (as a new process)

Che and workspace.next
In Eclipse Che, it is now possible to use sidecars for the workspace.

Let see how to apply this pattern to theia plug-ins.

Usecase 1: hello world theia plug-in.
In this case, the plug-in has no external dependency, it’s pure nodejs so there is no need to use a dedicated container

Usecase 2: openshift theia plug-in.
In this case, the plug-in has external dependency to oc tool, so there is the need to use a dedicated container. Plug-in is loaded from a shared filesystem like /theia-plugins

Usecase 3 : same than before but plug-in is embedded inside the image
Theia plugin-ext runtime will find this plug-in as it is for example in /embedded-theia-plugins folder

Usecase 4 : I have 5 plug-ins using the same version of oc tool. So it could spawn each plugin in its own container (like usecase 2) but instead, these 5 plug-ins could share the same container

Usecase 5: I have 5 plug-ins using oc tool. 3 of them rely on oc v3.5, 2 of them on oc v3.6
In that case, they will be grouped by runtime docker image:

Theia broker
The broker will be responsible of picking up required containers for the given set of theia plug-ins and providing endpoints to remote “plugin runtime” (provide a list of all endpoints and probably assign some ports for each theia remote endpoint.

Example for the latest use case:

Broker will return oc 3.5 container (C1), oc 3.6 container (C2) to the workspace.next engine
It will also assign the port 10000 for theia endpoint C1 with name : theia-endpoint-oc35, 10001 for theia endpoint in C2 with name theia-endpoint-oc36

It will provide that data to the theia container:
Can be through env var like
1/ env variables
THEIA_ENDPOINT_OC35_IMAGE=eclipse/che-oc3.5
THEIA_ENDPOINT_OC35_PORT=10000
THEIA_ENDPOINT_OC35_NAME=theia-endpoint-oc35

THEIA_ENDPOINT_OC36_IMAGE=eclipse/che-oc3.6
THEIA_ENDPOINT_OC36_PORT=10001
THEIA_ENDPOINT_OC36_NAME=theia-endpoint-oc36

2/ file
Or through a file that theia can get

All plug-ins are copied into /che-theia-plugins

Main Theia process, on start, will read all these plug-ins metadata, decide which plug-ins will run on which “theia runtime” and will distribute plugins loading order to all “remotes”.

It will distribute to C1 endpoint the order : load plugin1, plugin2 and plugin3
It will distribute to C2 endpoint the order : load plugin4 and plugin5

[garagatyi]

@l0rd @sleshchenko @skabashnyuk We probably need to think through the way how (and where) we would define the plugin broker that needs to be used for a plugin delivery.

[skabashnyuk]

in editor definition.?
https://github.com/eclipse/che-plugin-registry/blob/master/plugins/org.eclipse.che.editor.theia/1.0.0/meta.yaml

[l0rd]

@skabashnyuk but an editor can run different types of plugins (e.g. theia can run che plugin and theia plugin for instance)

@garagatyi I was thinking that's defined in the Plugin Type: https://github.com/eclipse/che-plugin-registry/blob/master/plugins/che-service-plugin/0.0.1/meta.yaml#L

[garagatyi]

@l0rd yeah, we can use plugin type to find a broker implementation that needs to be used.
I have a couple of use-cases that we need to think through before making changes:

1. A user chooses 2 plugins and one of them is Theia plugin and another one is Che plugin.
   In this case, we would need 2 plugin brokers and we can't start them in parallel because both of them would require the same volume.
   We can:
   1.1. Add a code that would combine all plugin brokers into a single pod and let all of them be executed in parallel
   1.2. Make Che plugin broker also support Theia plugin brokering (not sure it makes sense from the extensibility point of view)
2. How can other plugin brokers be added? I recall that we discussed such a possibility before. Does the plugin broker have to be merged in Che to be available for a user? Can we just add an ability to add plugin broker to some registry (Che plugin registry?) and use it?

[l0rd]

@garagatyi good questions:

For the first question I think we should do what you mentioned in point 1.1.
For question n.2 I think it's out of EclipseCon milestone scope but we should have in mind that - in the future - brokers will be plugged at runtime. I guess that adding brokers in the plugin registry is a good idea (for after EclipseCon Europe).

[benoitf]

FYI I've updated issue description

[l0rd]

@benoitf what about using labels on containers instead of environment variables to let Theia discover its plugin?

[benoitf]

@l0rd discussion is open. I thought it is easier to grab env variables than having access to labels when you're inside the container.

[garagatyi]

@l0rd @benoitf To be on the same page I would want to sync on the expectations for the current stage.
We decided:

1. Use 1 sidecar container for 1 remote plugin
2. Get plugin info from meta.yaml in the plugin registry
3. Get sidecar info (dockerimage, etc) from tar.gz archive of the plugin. Link to the archive should be in meta.yaml.
4. Theia broker should
   • Unpack archive
   • Copy it to plugins volume
   • Set env var with port to plugin sidecar
   • Set 2 env vars with info about remote plugin endpoint to Theia container
5. Theia container would get 2 env vars, would analize info in remove plugin package.json that has to be in the plugin folder in Theia container and start it in remote plugin container

If I'm missing something or you believe that we agreed on something else, please, comment.

[benoitf]

I thought that we decided that broker was working directly with .theia file (no .tgz archive) and info coming from package.json inside the .theia file. (.theia file is a zip file)

about 4. when we discussed we agreed on
broker:

• download all theia plugins, unpack them in /plugins/, /plugins/
• assign some ports like 10000, 10001, 10002 for every theia endpoint
• need to mount /plugins to every theia container (main and endpoints)
• provide env var to
  • main theia container : THEIA_PLUGIN_REMOTE_ENDPOINT_che_che_fortune_plugin=ws://foohost:10000 (plugin-id) (only if the plug-in needs to be run in its own container, else no env var)
  • endpoint container: THEIA_PLUGIN_ENDPOINT_PORT with the value computed before

about 5. it will receive only one ENV VAR THEIA_PLUGIN_REMOTE_ENDPOINT_che_che_fortune_plugin=ws://foohost:10000

[l0rd]

@garagatyi with @benoitf corrections looks good to me.

Just one thing: why do we need to mount the /plugins/ volume in the endpoints containers? Can't we just include the .theia file in the container image?

[l0rd]

@benoitf another concern I have is how the broker is supposed to know what is the sidecar docker image (step 3.)? In the meta.yaml there will be only an URL to a .theia file.

[benoitf]

@l0rd
about

Just one thing: why do we need to mount the /plugins/ volume in the endpoints containers? Can't we just include the .theia file in the container image?

We said that we supported usecase of plug-ins outside of the image first, so it needs to be accessible in some ways

@benoitf another concern I have is how the broker is supposed to know what is the sidecar docker image (step 3.)? In the meta.yaml there will be only an URL to a .theia file.

@l0rd , the approach used by @garagatyi was to add in che-plugin.yaml

id: che-fortune-plugin
name: fortune
containers:
 - name: theia-fort-pl
   image: wsskeleton/fortune
   memory-limit: "700Mi"
   volumes:
       - mountPath: "/plugins"
         name: plugins
       - mountPath: "/projects"
         name: projects

but in .theia file, in package.json there is usage of the container https://github.com/ws-skeleton/che-fortune-plugin/blob/master/package.json#L27 so it can be read from there as well

[garagatyi]

@benoitf How do you think do we need this issue or it is kinda outdated?

[benoitf]

@garagatyi well, now endpoint is handling all usecases so broker still need to be updated to handle these AFAIK (like supporting plug-ins directly inside the image, etc)

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.