Reuse devfile runtimes as LS sidecars to minimize the number of images required in CRW 2

[l0rd]

Is your enhancement related to a problem? Please describe.

Currently the sample stacks base images are unrelated to the corresponding language servers sidecars (i.e. java8 plugin and the maven jdk 8 stack).

As a consequence users can experience some inconsistencies as mentioned by #14545

Describe the solution you'd like

When #13387 will be addressed we will be able to use the same images for some stacks and the sidecar. The images may match or be based on (one layer on top of) the language server sidecar image.

That solution only solves the problem of the samples stacks provided with Che. To help users address the same problem for their custom stacks we should document how to customize the sidecar image (in a customer plugin registry) to match the language version of their runtime.

[ibuziuk]

@l0rd do you have in mind which team / individual this issue should be assigned to ?

[tsmaeder]

That solution only solves the problem of the samples stacks provided with Che. To help users address the same problem for their custom stacks we should document how to customize the sidecar image (in a customer plugin registry) to match the language version of their runtime.

I don't think forcing our users to run custom images for plugins is the way to go: it's a step back to the world we had in Che 6.
If this is about solving the "debugger source mismatch" problem for JDT, I would envision a solution that allows us to somehow "mount" the jdk of the dev machine in the sidecar.

[tsmaeder]

Or if we're going down that rabbit-hole, why not go all the way and run the tooling plugins inside the dev-machine image? We would get rid of all those pesky cross-container problems ("cannot open file", etc.). We'd have the same model as Gitpod or VS Code Remote Extensions.

[l0rd]

Or if we're going down that rabbit-hole, why not go all the way and run the tooling plugins inside the dev-machine image? We would get rid of all those pesky cross-container problems ("cannot open file", etc.). We'd have the same model as Gitpod or VS Code Remote Extensions.

I am ok with that as far as it doesn't require the users to "patch" their stacks to run our stuff.

Hence I think that it should be optional: even if the plugin meta.yaml specifies a sidecar image users may override that in the devfile. Something like:

components:
  - alias: maven
     type: dockerimage
     image: eclipe/maven-jdk8:latest
  - type: chePlugin
     id: redhat/java/latest
     runInComponent: maven

[l0rd]

@ibuziuk I think that we still need to figure out how to implement that. There are 3 options:

1. a devfile registry modification only: as soon as Theia remote plug-in runtime in sidecar container improvement #13387 get fixed we update the stacks images to match the LS images

2. we update the devfile spec to allow overriding the plugin sidecar image (and then we update the LS images in the devfiles in the registry):

components:
  - type: chePlugin
     id: redhat/java/latest
     spec:
       containers:
         image: eclipe/maven-jdk8:latest
         name: vscode-java

3. we update the devfile spec to allow running a plugin in an existing component (and then update the devfiles in the registry)

components:
  - alias: maven
     type: dockerimage
     image: eclipe/maven-jdk8:latest
  - type: chePlugin
     id: redhat/java/latest
     runInComponent: maven

I think we can eventually iterate over these 3 options: first we only update the image in the devfile, then we allow users to specify a plugin image and finally we allow users to specify a component that will "host" the plugin.

cc @nickboldt @skabashnyuk @sleshchenko @benoitf

[l0rd]

cc @davidfestal

[nickboldt]

WIP is happening in #14797

[nickboldt]

List of images in devfile reg:

$➔ ./build/scripts/list_referenced_images.sh devfiles/
quay.io/crw/stacks-cpp-rhel8:2.0
quay.io/crw/stacks-dotnet-rhel8:2.0
quay.io/crw/stacks-golang-rhel8:2.0
quay.io/crw/stacks-java-rhel8:2.0
quay.io/crw/stacks-node-rhel8:2.0
quay.io/crw/stacks-php-rhel8:2.0
quay.io/crw/stacks-python-rhel8:2.0
registry.redhat.io/rhscl/mongodb-34-rhel7

List of images in plugin reg:

$➔ ./build/scripts/list_referenced_images.sh v3
(new in 2.0)
quay.io/crw/machineexec-rhel8:2.0
quay.io/crw/theia-endpoint-rhel8:2.0
quay.io/crw/theia-rhel8:2.0

(reused from CRW 1.2 stacks, with updates to work in 2.0)
quay.io/crw/stacks-cpp-rhel8:2.0
quay.io/crw/stacks-dotnet-rhel8:2.0
quay.io/crw/stacks-golang-rhel8:2.0
quay.io/crw/stacks-java-rhel8:2.0
quay.io/crw/stacks-php-rhel8:2.0
quay.io/crw/stacks-python-rhel8:2.0

(new LS sidecars)
quay.io/crw/plugin-kubernetes-rhel8:2.0
quay.io/crw/plugin-openshift-rhel8:2.0

[nickboldt]

I think we're as done here as we're likely to get.