New workspace model to run VS Code as a Che editor

[benoitf]

Is your enhancement related to a problem? Please describe

We want to add VisualStudio Code as a Che editor, support running VS Code extensions, use devfiles to define the containers to build, debug, test and run applications.

The workspace model used by Theia consist on a pod with:

• the devfile containers
• a nodejs container where Theia runs
• some sidecar containers to run VS Code extensions
• the machine-exec and gateway containers

In this model Theia and the VS Code extensions run in their own sidecars.

That required a fair amount of work Che side because Theia and VS Code extensions are designed to run in the same host, having access to the same filesystem, network, processes etc...

Unfortunately the work done to adapt Theia to this mode is not reusable for VS Code: running VS Code and his extensions in separate containers do not work out of the box. It would take months to patch VS Code to make it work and after that, a fair amount of time to maintain and keep up with the VS Code extensions API.

Describe the solution you'd like

Considered the difficulty to adapt current workspaces model to VS Code we have been looking at the alternative 2 and 3 described in #17209 (although that issue is NOT about VS Code, the solutions can be applied here too):

• alternative 2: VS Code runs in one container and the extensions run in a devfile component (a “user container”)
• alternative 3: VS Code AND the extensions run in a devfile component (a “user container”)

Alternative n.2 is already possible with Che-Theia with Devfile attribute che-theia.eclipse.org/sidecar-policy: USE_DEV_CONTAINER. This is currently used in the new Devfile v2 Che samples:

For VS Code the only alternative is n.3 since the editor and the extensions need to run in the same container:

• VS Code and its extensions will be downloaded from the plugin registry into a volume and then mounted in one of the workspace components
• Devfiles will still allow people to have multiple containers (like one container with java, another one with a database) but the recommendation is to keep all development tools in one container for VS Code extensions that require them and for a developer opening the terminal expecting all his tools available.
• Opening a terminal should be defaulted to a single container as well
• When the workspace doesn’t include any container (because there is no devfile for example) the universal development image should be used

Describe alternatives you've considered

Running VS Code and extensions in their isolated sidecar. We mentioned that we initially discarded this alternative because we would need to patch VS Code and requires months of work and years of maintain. It has a few extra drawbacks too:

• dev tools (npm, mvn, kubectl, etc…) are in multiple containers and users get confused when asked to chose the terminal’s container (Simpler user experience for working with terminals with an ‘all-in-one’ approach #17209)
• dependencies between extensions cannot be handled: there is a problem to have synchronous calls over asynchronous remote endpoints

Running VS Code with all the extensions in an isolated sidecar. That’s close to what Theia does today and the main problem with this approach is that the same tools need to be present in both the sidecar (because VS Code extensions require them) and in the user components (because the user wants to have them in his terminal), so how do we make sure that there is no skew between those 2 containers?

There is an ongoing work on https://github.com/katalogos (Containerized Software Catalogs for Kubernetes). This is something that we should consider in the future but currently it’s still experimental.

---

FAQ

Are the issues with the sidecar model the main motivation for this change?

No. We need to start over for VS Code and the new model is cheaper. That's the main reason. The fact that the sidecar model has some issues (described in the "alternative you have considered" section) helped to make this choice.

How is the editor executable injected in the user container? Is the file included in an initcontainer image at build time?

The editor executable is published in the plugin registry. It's downloaded from there and put in volume at the workspace startup. To improve startup time we want to avoid downloading if it's already there or even pre-download it at namespace creation.

How does the devfile that defines an editor in such a configuration looks like?

That's a devfile with one component associated to a pre-start command like this one. What's missing today is the support for post-start commands, already part of the Devfile 2.x spec, but not implemented by the DevWorkspace controller.

How can we request memory/cpu for vs code and its extensions if they are "injected" in a devfile component that already has its own mem and cpu request?

We should definetely sum up the CPU/memory requests/limits of the editor and extensions with that of the container that will host them. The probem is how are we going to specify those requests/limits. Editors and extensions devfile doesn't include them. That's something to discuss. I see a few options:

1. Use a devfile attribute (e.g. resources.limits.cpu: 1)
2. Add CPU/mem limits/requests for commands in the devfile spec
3. Always specify a container component with specified resources that has an attribute devfile.io/backup-component-only: <component-name>

What component should be used when no component can host vs code and the extensions? (i.e. there is no devfile in the repo, the user devfile has no component, the only component is a runtime where sources are not mounted)

That's something to discuss. One idea would be to:

• in the editor devfile specify a backup component with attribute devfile.io/backup-component-only: <component-name>
• in the user devfile the editor/extensions aren't injected in components that have mountSources set to false
• in the user devfile the editor/extensions are injected in the component identified by the attributethe devfile.io/ide-terminal-component: <component-name> first component that has mountSources: true

Can we make progress along this proposal without initially supporting editor injection?

VS Code doesn't support remote extensions so the only alternative to this proposal would be injecting the extensions in the VS Code sidecar. If the IDE sidecar doesn't have the prerequisites to run an extension, the user will need to modify the editor sidecar, something that he doesn't really control. If instead we inject the IDE and extensions in a container that's defined in the Devfile, the user would update a container he does control.

Why not to run Theia in the same way?

It's a matter of iteration. Let's do that for a new editor, VS Code, so we do not have to worry about the default editor (Theia). If we see that this works for VS Code than we can use the same model for Theia too.

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