Workspace Loading Sequence

[slemeur]

Goal

The ultimate goal of this specification is to provide a fast and unified loading sequence for the workspace inside of the IDE. This sequence is important, because we want the user to be able to interact with files and terminal as fast as possible.
Until interactions on files and terminals are enabled and instead of being a dead space, it is important to:

• Introduce workspace's main components
• Provide level of information on what's being done

From user perspective, once interacting with the workspace is enabled, other elements like auto-completion, code analyzis and other tools which might be requiring other agents can be lazy-loaded in a second time.

Currently in the product, we have different sequences which are perturbing the users.
We initially wanted the user to land in the IDE only once everything is ready and loaded. It means that until the workspace is not fully created and booted, we ask the user to wait without being able to do anything. We had a loading sequence with a crane animation illustrating and explaining the construction of the workspace with each pieces. We changed that sequence for the case of creating a workspace from the dashboard to a flow where we open the IDE and show console outputs of the workspace startup operations.
We have the following issues that we would like to address with this specification:

• inconsistent loading sequences
• console outputs are too noisy and not helpful to end-user
• interactions are blocked until everything is fully loaded
• agents are loaded one after one which makes the loading sequence very long

As part of this specification, there are various flows that have to be handled:

• Access to a workspace from the Dashboard
• Direct access to the workspace (for example integrated into a 3-part tool)
• Factory sequence
• Chefile sequence

Related issues

#5144


Details

Workspace elements to get loaded

Current loading sequence

There are certain elements that needs to be loaded before the user would be fully ready to work on his workspace.

1. Docker Build or Image Pull
This element depends on the workspace's recipe - an image will always be pulled (until it is on our cache) and maybe other docker instructions will be added which will require a Docker Build.

2. Create container
Once the image is there and built, we need to start it and create the workspace's machines (=containers)

3. Install exec agent and start exec agent
The exec agent, is the agent running is the workspace and allowing to instruct commands for execution inside of the workspace's runtime.

4. Install and start terminal agent
The terminal agent, is the one that allows the user to get a terminal in his workspace, for all the machines defined.

5. Start tomcat for ws-agent
This step could be quite long. We download the ws-agent and then starting it. As part of the startup process, there is a tomcat server which is starting inside of the workspace's dev-machine. It load JARs / Java classes and then it provides Project API - which basically allow the user to interact with the project (get the project explorer, open/edit files...)

6. Start other configured agents
If the workspace is requiring other agents to be enabled, those agents will get executed right after ws-agent is started. They will be started sequentially. Each agents, might require dependencies to be downloaded and installed in the workspace runtime.

Once those 6 steps are done, the workspace is considered as fully loaded and ready for the end-user.



Identified issues in the current loading sequence

Sequential Loading

• All the different steps are executed sequentially, they are not parallelized. As it is perfectly understandable that it could have a logical loading sequence with the initialization of the workspace - there could be optimizations in order to fasten the loading flow.

Lazy Loading
Agents are loaded as part of the workspace definition, there is no lazy loading enabled.
For example:

• I might have enable the JSON Language Server in the workspace's configuration
• Agent for JSON LS is installed and started even if I don't have any JSON file opened.

This makes the loading sequence heavy and impact the user feeling on the product performance.

Those points needs to be taken into account as part of the fundamental work done on the SPI #4736

Pre-loading of the IDE JS

Today, we load the IDE code, only once the user clicks to open a workspace which creates some unnecessary latency where we are displaying a glowing logo. We need to improve that behavior, so that the IDE code is preloaded - ready when the user needs it.

Starting from Dashboard:

• The Dashboard is the main entry point for the user once Che is booted. As a consequence, we are able to load the IDE directly when the user is on the Dashboard.

Starting from Chefile - Factory - or 3-part tool:

• The IDE might not be loaded and cached yet: in this case, we need to display a page to the user until the IDE is loaded.

Modules activation in the IDE

The goal of this section is to identify the different parts of the IDE which can be activated depending on the loading sequence.
We can define the following modules:

• Command controller
• Terminal
• Editor
• Project explorer

Step-1: Docker Build or Image Pull

During this step, the workspace's runtime is not yet present, so no interations will be enabled in the IDE.
We will display the IDE in loading mode:

• the command controller will be used to show the loading status
• the terminal will be shown in intialization state + used to show loading details
• the editor and the project explorer will be shown in loading mode

[TBD: Error case, when the workspace's runtime failed to build/pull]
It will be possible to see the completed outputs.



Step-2: Create container

During this step, the workspace's runtime is still not yet present, so no interations will be enabled in the IDE.
We will display the IDE in loading mode:

• the command controller will be used to show the loading status
• the terminal will be shown in intialization state + used to show loading details
• the editor and the project explorer will be shown in loading mode

[TBD: Error case, when the workspace's runtime does not start]



Step-3: Install exec agent and start exec agent

During this step, the workspace's runtime is present but the exec agent is still necessary to interact with it.
We will display the IDE in loading mode:

• the command controller will be used to show the install and starting status of the exec agents
• the terminal will be shown in intialization state + used to show loading details
• the editor and the project explorer will be shown in loading mode



Step-4: Install and start terminal agent

During this step, the workspace's runtime is present but the terminal agent is still necessary to interact with it.
We will display the IDE in loading mode:

• the command controller will be used to show the install and starting status of the exec agents
• the terminal will be shown in starting state
• the editor and the project explorer will be shown in loading mode

Once the terminal agent will be enabled, we will visually active the terminal (UI animation) and display a message in the terminal

Terminal will become fully available.



Step-5: Start tomcat for ws-agent

During this step, the ws-agent will get downloaded and started.
We will display the IDE in loading mode:

• the command controller will be used to show the download progress of the ws-agent and the dependency that is also injecting.
• the terminal will be activated
• the editor and the project explorer will be shown in starting mode

Once ws-agent is loaded, we will reveal the content of the project explorer with an animation.
For the editor, we will also open:

• restore the previously opened files (if exist)
• open the readme.md file (if nothing else defined)

Preloading the editor, will also allow to initiaze orion inside of the IDE.

Project Explorer + Editor are becoming fully available.



Step-6: Load other agents

At this stage, the workspace is available and we allow the user to interact with every parts of the IDE.

All the other agents, will be downloaded asynchronously, in a parallelized way and not block the user.
Features, provided by agents will get enabled based on the loading of the agents.

For example:

• SSH will get enabled once the agent will get ready
• LS will allow code completion only once ready (we will display a message in the autocompletion box to show "Initializing Language Server")

We will display the loading of those agents, using a toast displayed in the bottom right corner. User will be able to click on the toast to get details.

[slemeur]

We need to consider this specification as a UI and UX exercise in order to provide a smoother loading experience - from user perception.

We'll have a separate issue to work on various improvements we can do, to make the user being able to interact with the files as fast as possible.

[garagatyi]

I have concerns about plugin team being able to implement this UI.
Stuff like an image pulled, container started are not provided by the server side in infrastructures compatible way. Pulling output is not provided on OpenShift at all. So now we can implement something similar only for Docker infrastructure. Which seems not very interesting because of incompatibility with the OpenShift infra.
Can we discuss whether this task is needed and how to implement it?

[gazarenkov]

As mentioned by @garagatyi above it is hardly possible to make it unified for all the types of infrastructure since it heavily depends on events/messages/output emitted by concrete infrastructure.
In general the client can:

• react on "know" (generic and known implementation) events "unified" way (nicely)
• show as it is or ignore other events

So the manner of displaying it should be considered case-by-case

[slemeur]

Ok so the underlying infrastructure behaves differently and produce different events, messages, outputs. The SPI gives the ability to make Che agnostic to the underlying infrastructure. I don't see any reason why the SPI would not provide unified messages to display informative outputs when we are starting a workspace.

From a end-user point of view, the underlying infrastructure is not something that is important and it must not impact the user experience. What's matter is the sequence of events that are happening when a workspace is starting. Today, the sequence looks like this:

1. Pull workspace machine(s) images
2. Start workspace machine(s)
3. Inject and start exect agent
4. Inject and start terminal agent
5. Inject and start ws-agent
6. Start other configured agents

Those events (today) are consistents accross the different infrastructure implementations and the server (SPI) must provide those events in an unified way to the client(s).

Example on the pulling of images, you could have:
1- an event when starting to pull an image
2- an event when image pulled
3- an event for sending pull progress information

If -3- is not present, then the client(s) will just not show the progress, but a basic loader.

So instead of forwarding the events from the infrastructure, the SPI intercepts them and send them in a way that is convenient and unified. That's the only way we can provide a consistent user experience accross different client(s) independently from the underlying infrastructure.

I don't see any reason why the SPI would not be able to handle that.

[ghost]

In case of OpenShift, the following events are available:

Started
pods/che-1-2gsk9
Started container

Pulled
pods/che-1-2gsk9
Successfully pulled image "registry.devshift.net/che/che:ee46279-fabric8-fac865a"

Created
pods/che-1-2gsk9
Created container

Pulling
pods/che-1-2gsk9

However, if in case of Docker it's possible to parse logs and show image pull progress bar, it is not the case with OpenShift.

[garagatyi]

@slemeur yes - it is what we can implement without depending on any particular infrastructure. It is exactly what I was thinking about. Sorry, if I was not clear.
Also, I believe all these events ARE optional since we are not able to force every infrastructure to send any events, so the client should be aware that it is possible that no events may come at all.

[slemeur]

For Che 6 GA we target the following scope:

• Add missing loading pieces: installers info #7330
• Loading progress is shown twice while IDE is loading [CHE 6] Loading progress is shown twice while IDE is loading #7581
• Add proper IDE events/handlers for workspace loading flow Add proper IDE events/handlers for workspace loading flow #7332
• Add ability to retrieve the outputs of each machines
• Handle error cases
• Openshift support for the loading sequence
• Once workspace is started - we need to display the regular placeholder (open file/project) or restore the state of the IDE
• Add more space between icon and title on tabs in the Processes panel