Faster workspace startup experience

[slemeur]

Goal

One of the most important value prop of Eclipse Che is the disposable and on-demand aspect of the developer workspaces, which shift the development paradigm. It is also key in the adoption of tools, developer love when it is fast.

Problem
With the introduction of Che 7 based workspaces, the loading time of the workspaces has been growing significantly. A workspace is going to pull more containers and the load of the binaries of the extensions is also going to impact the loading performance.

Prioritized components load / minimal pull of images and components / lazy loading

When a user is starting a workspace, the workspace should start a very small subset of containers. For example only the Editor part. Then, VS Code Extensions, are downloaded in the background as well as all the specific runtimes. When the tooling is ready, the workspace is updated and a rollout upgrade of the Editor (Che-Theia) is used.
Che-Theia has now the whole tooling ready and user is notified. It can be an incremental upgrade of the editor (like every 5s for every plug-in being ready, for every plug-in ready, etc).

Optimized broker / init containers

The plugin broker shouldn’t download the VS Code extension vsix at each workspace start. We could include the extension in the runtime image built offline. Then restarting a workspace or starting a workspace with the same VS Code extensions than a previous user will reuse container images.

Cache of images and components

When an image, a plugin’s binary, a component has been pulled that should be cached and available to all the users.

List of Subtasks

• Plugin Broker refactoring #14494
• Adapt Hosted Che 'k8s-image-puller' to the upstream needs #15385
• Use a reverse proxy to avoid routes/ingress creation at workspace startup #12914
• Reduce workspaces restart time #18672
• Provide rapid workspace starts in a read-only manner as more complete experience loads in background or on a refresh #19461
• Asynchronously attach PVs to Workspaces #15384
• Pre-build DevWorkspace templates for devfile v2 of devfile registry #19718
• Avoid re-downloading the same extension again and again #20592
• Investigating faster workspace startup devfile/devworkspace-operator#209
• Use a PV to cache users VS Code binary

[amisevsk]

Added a subtask that has an existing issue.

@slemeur I'm not clear on what the last topic entails:

• Images are available to all users by default (since they're stored in the internal image repo on the cluster; however this is on a node-by-node basis.
• Would offline support for the plugin registry solve the plugin's binary component? Currently it's possible to build a plugin registry that has all extensions to be downloaded served locally. If so, there's a few tasks left on this: [plugin registry] Do not reference marketplace.visualstudio.com in plugin registry meta.yaml #14573 (comment) (could be a subtask attached to this epic)
• The offline registry above also impacts the first point (lazy start of components), since the offline registry enables Che to pull in plugin artifacts very quickly in many cases.

Regarding the first point, I think more investigation would be necessary; in my experience, the starting of the containers isn't the biggest problem, it's pulling images and waiting for Theia to be responsive. Integrating a rollout into the start process may wipe out much of the time saved if Theia has to restart.

[frank-dspeed]

I don't expirence any issues on a real cluster. with a dedicated docker registry proxy and a vscode extensions proxy local to the cluster. i also use apt and yum proxys and node npm proxys its part of my general flow as i always want to have a copy of all needed packages.

[monaka]

On the online approach, eclipse-che/che-plugin-broker#63 may provide some helps. In addition, the download phase can be done in parallel.

And it may be effective pre-loading docker images to nodes by DaemonSet.

[sunix]

Should this include the work started by @davidfestal on CRDs and remove the SPI ? we would gain 10 secs sometimes.

[l0rd]

ImagePull policies set to IfNotPresent make workspace startup faster #14698 (comment).

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

[l0rd]

Related to devfile/devworkspace-operator#209