Plugin broker should send plugins configuration with separated init container that downloads plugins

[garagatyi]

Description

At the moment the plugin broker downloads a plugin binaries and put them in plugins volume /plugins in a sidecar or in the main theia container.
When we start ephemeral workspace this leads to running the broker twice which is error prone and not time effective.
Instead of that the broker should return a configuration of plugins with init containers and configuration on what needs to be downloaded and where to put that.

Additional info from here and here:
Instead of sending brokering results as it is sent now plugin-service-response-v1.yaml, send results in form which would allow implementing automatic plugins sidecar co-location plugin-service-response-v2.yaml. See explanation here. Automatic plugins co-location feature would also affect ability of UD to get RAM limits for the whole workspace - we will need to find solution for that.
Separate sidecar config evaluation and binaries delivering to workspace:

1. Do not support setting container image in Theia plugins using engine.cheRuntimeContainer in package.json. Container image has to go into meta.yaml starting from apiVersion: 2. This will help avoid confusion when image is set in both meta.yaml and package.json.
2. Rework theia remote sidecar connectivity approach on brokers side to avoid downloading VS Code extension archives to evaluate plugin name and publisher from package.json. This would help splitting sidecar configuration and binaries downloading phases and will speed up workspace start. See Florent’s comment about available options here
3. Create new golang based tiny program that can download binaries and put it in specified locations. Let’s call it download container.
4. Rework broker to return download container config with plugin binaries location as part of sidecars definition. This should not involve any downloading on the sidecar definition evaluation stage.
5. Make ws master use download container as init container(s) in workspace.

Reproduction Steps

OS and version:

Diagnostics:

[garagatyi]

@l0rd @ibuziuk

[l0rd]

@garagatyi I have tried to read this a couple of times but I struggle to understand it. We may need to do a call. @ibuziuk what do you think?

[garagatyi]

@l0rd I'll try to rephrase the description:
Now:
1.1 broker is started
1.2 broker generates sidecar config
1.3 broker downloads archives of plugins and put them in /plugins folder
1.4 if workspace is ephemeral steps 1.2, 1.3 are repeated in a broker running as init container of the workspace
We need to change it to:
2.1 broker is started
2.2 broker generates sidecar config and download config (but doesn't download plugins)
2.3 workspace is started with init containers and download config
2.4 init containers download/unpack/copy files according to download config

It effectively separates sidecar config evaluation and plugins downloading, so:

• allows making broker persistent micro service and reduce workspace start time by avoiding waiting for broker deployment to start
• allows removing second run of brokering for ephemeral workspaces which also cuts workspace start time
• allows caching sidecar configuration which speeds up workspace start

[l0rd]

Ok I see. That looks good to me.

[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.

[amisevsk]

Out of date; current plugin broker issue #14494