Move preparing of RuntimeContext to the async phase of workspace start

[sleshchenko]

Description

Preparation of RuntimeContext may last a long period of time, like when Infrastructure needs to fetch images or send few requests during context preparing.
But it leads to issue with interruption of start workspace request. It happens because it is performing synchronously (see related code here). And browser interrupts requests if they last more than 30 seconds.

To fix this issue and make it possible to perform long living tasks while RuntimeContext preparing it is needed to move preparing of RuntimeContext to the async phase of workspace start. So context preparation should be a part of the WorkspaceRuntime.StartRuntimeTask#run method.

Also, it is required to set workspace status to STARTING when infrastructure is preparing context.

Reproduction Steps

OS and version:

Diagnostics:

[garagatyi]

Since the creation of a runtime context is one of the points of extension of SPI there is a lot of reasons why it may last a long time. I think it is very frustrating if this cause long execution of workspace starts API which is supposed to be asynchronous API.
@sleshchenko I think we even might tag it as a bug.

[sleshchenko]

Update:
Also, it is required to set workspace status to STARTING when infrastructure is preparing context.

[sleshchenko]

Tried to move preparing of RuntimeContext to the async phase of workspace start and found out that there is an issue with cancelation. It is supposed that the workspace start may an interruptible process if infrastructure supports it (as docker, kubernetes, openshift support do).
There should be an ability to cancel context preparing as well when it will be moved to async part and long tasks can be submitted here.
SPI interface should be adapted to support it:

• maybe contexts should be cached by WorkspaceRuntime instead of caching of runtimes;
• infrastructure should return something like cancelable future or context should provide a method for preparing interruption;
• Infrastructures implementations should provide their own context preparing cancelation, the same as it is done with runtime start interruption;

As a temporary solution for plugin broking, it was decided to move it into runtime start phase as a quicker way to make a start of workspaces with plugins stable. Moving preparing of RuntimeContext to the async phase of workspace start should be investigated more, and the corresponding changes for SPI interfaces should be prepared for further discussion.

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