Simplify the troubleshooting of an editor start-up issues: Show an editor's logs on the Dashboard

[azatsarynnyy]

Is your enhancement related to a problem? Please describe

When there is an editor start error that prevents a Workspace from a successful launch, the user:

• sometimes, sees the blank page instead of the editor

• in some cases, they can get the following error on the Dashboard:
  
  which often means there's an editor start error

• etc.

To troubleshoot the issue and get the editor start error details, one needs to:

1. Go to the OpenShift Console
2. Open a terminal to the container where the editor is running
3. Get the content of the log file where the editor process outputs. See the screenshot:

Or get the log file content through the CLI.

The log file can be found in the editor's devfile, e.g. che-code, idea-server

Problem:
It takes a lot of redundant steps (and deeper technical knowledge of the editor start process) even for an experienced user.
For the regular user, it's very hard to investigate what is the problem with their Workspace start, without an expert's help.

Describe the solution you'd like

The Dashboard could provide a simple way to view the editor output.
For example, as a dedicated item in the containers' logs list:

So, the non-experienced Che user will be able to view the editor's logs just in a couple of clicks.

Describe alternatives you've considered

If it's hard to implement on the Dashboard side,
(or in addition to the suggested solution)
it can also be a hint on this popup, that could guide the user where to look for an editor logs to see the potential error

Additional context

The path to the editor's log file can be provided as an editor devfile attribute.

[ibuziuk]

@azatsarynnyy @olexii4 @akurinnoy editor's logs are currently not propagated to the Logs tab?

if this is the case we should definitely fix it

[akurinnoy]

@ibuziuk currently, the editor's logs are not propagated to the dashboard side

[azatsarynnyy]

Once, we reworked the editor start process from the sidecar approach to the shared volume approach,
an editor is running by a post-start command which outputs to a file:

• https://github.com/eclipse-che/che-operator/blob/aa0150d74fe0db59f475192ba13230c68dfd7e72/editors-definitions/che-code-insiders.yaml#L78
• https://github.com/eclipse-che/che-operator/blob/aa0150d74fe0db59f475192ba13230c68dfd7e72/editors-definitions/che-idea-server-next.yaml#L80

I think the Dashboard can watch the file content, by the known path, with the k8s client.
The file path can be taken from the editor's devfile, in the attributes, if provided
https://github.com/eclipse-che/che-operator/blob/aa0150d74fe0db59f475192ba13230c68dfd7e72/editors-definitions/che-code-insiders.yaml#L140

[vitaliy-guliy]

I think we should not connect the editor logs with the dashboard.
And the delay in 300 seconds looks like not the editor issue.

@azatsarynnyy in your case, what was the problem of the failure?

[azatsarynnyy]

Thank you for your feedback @vitaliy-guliy

I think we should not connect the editor logs with the dashboard. And the delay in 300 seconds looks like not the editor issue.

@vitaliy-guliy Such failure of starting a workspace often (not always, of course) means the Dashboard can't get the editor's link during the timeout.

@azatsarynnyy in your case, what was the problem of the failure?

@vitaliy-guliy The problem was caused by a pretty common issue - there was an editor start failure, so the Dashboard couldn't get the editor link during the timeout.
To know the root cause, it need to look at the editor's startup logs.

[vitaliy-guliy]

@azatsarynnyy in your case, what was the problem of the failure?

@vitaliy-guliy The problem was caused by a pretty common issue - there was an editor start failure, so the Dashboard couldn't get the editor link during the timeout. To know the root cause, it need to look at the editor's startup logs.

Could you share how the error can be reproduced?

[azatsarynnyy]

@azatsarynnyy in your case, what was the problem of the failure?

@vitaliy-guliy The problem was caused by a pretty common issue - there was an editor start failure, so the Dashboard couldn't get the editor link during the timeout. To know the root cause, it need to look at the editor's startup logs.

Could you share how the error can be reproduced?

@vitaliy-guliy It requires having an editor image with some editor start failure which prevents the Dashboard from getting the editor link.

[azatsarynnyy]

I noticed the issue description and title were not very clear.
@vitaliy-guliy I updated it to better show that it's not about the timeout warning, but about simplifying the troubleshooting process of an editor launch in general.
Instead of the timeout warning, it can be just a blank page with an editor, etc.
The main point is that it requires looking at the editor's start-up logs.

[vitaliy-guliy]

@azatsarynnyy well, you want to show the editor output into the dashboard just to better understanding what's going wrong on the editor side. Ok, then I would propose to specify a file/resource smth like /logs (a file in the container root). And instead of writing to /checode/entrypoint-logs.txt, put all the editor output to /logs.

If we put the file into a volume, its content will be saved even if workspace failed.

[azatsarynnyy]

@azatsarynnyy well, you want to show the editor output into the dashboard just to better understanding what's going wrong on the editor side. Ok, then I would propose to specify a file/resource smth like /logs (a file in the container root). And instead of writing to /checode/entrypoint-logs.txt, put all the editor output to /logs.

If we put the file into a volume, its content will be saved even if workspace failed.

@vitaliy-guliy I like the idea of persisting an editor's logs in a volume.
It can be the next improvement. So, the recent editor's logs can be viewed/analyzed event for a stopped workspace.