You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that we have launched the new CLI, the rate of installation success has improved significantly. The most common issue that prevents admins from getting a shared Che setup properly is network configuration that either prevents the Che server from reaching the workspace agent, or in how the browser connects to the workspace agent.
These issues are currently only detectable after a workspace has been started, and is usually shown to the end user with a hard to understand error message about lacking communications and an unhelpful stack trace.
The general objective would be to implement a series of tests as early as possible to detect likely issues, and if necessary, interrupt the startup of Che with helpful messages on what to configure to fix. And, in the situations where things can only be tested from within the user's browser, to provide a small UX utility in the UD that lets users run a series of tests from the browser.
Add preflight checks to Che startup that simulates server => agent and browser => agent connectivity using the same tests that are currently in info --network. If the wrong tests fail, interrupt with a statement of the likely cause of the problem and how to fix it. Skipp these tests (all preflight checks really) if --fast.
Add postflight checks to Che startup that performs server => agent communication on a real (tiny) ws with actual (minimal) ws agent. Just enough to allow us to start the smallest possible workspace with actual configuration and verify that agent can reach server and server can reach agent. If this fails, then we should print out error message to the console, but continue to let the server run. We should find a way to do this in the background after the Use: URL has already been printed to the screen. So we perform this post flight check and then print out a post-flight error message if we learn something. Also skip this if --fast.
Add in "diagnostics" button on the UD (next to documentation). This will load a page in the UD to perform browser->server and browser->agent specific tests. We should use this as a chance to detect if websockets work, if there are user | firewall issues, and whether the setting of CHE_DOCKER_IP_EXTERNAL is properly configured. You could imagine a series of tests that a user can run from within the browser and each test shows success or failure. This does not have to be nicely formatted - as it will be uncommon. For each failure condition, we should have helpful error message indicating what to do to resolve it
The text was updated successfully, but these errors were encountered:
Now that we have launched the new CLI, the rate of installation success has improved significantly. The most common issue that prevents admins from getting a shared Che setup properly is network configuration that either prevents the Che server from reaching the workspace agent, or in how the browser connects to the workspace agent.
These issues are currently only detectable after a workspace has been started, and is usually shown to the end user with a hard to understand error message about lacking communications and an unhelpful stack trace.
The general objective would be to implement a series of tests as early as possible to detect likely issues, and if necessary, interrupt the startup of Che with helpful messages on what to configure to fix. And, in the situations where things can only be tested from within the user's browser, to provide a small UX utility in the UD that lets users run a series of tests from the browser.
Add preflight checks to Che startup that simulates server => agent and browser => agent connectivity using the same tests that are currently in
info --network
. If the wrong tests fail, interrupt with a statement of the likely cause of the problem and how to fix it. Skipp these tests (all preflight checks really) if--fast
.Add postflight checks to Che startup that performs server => agent communication on a real (tiny) ws with actual (minimal) ws agent. Just enough to allow us to start the smallest possible workspace with actual configuration and verify that agent can reach server and server can reach agent. If this fails, then we should print out error message to the console, but continue to let the server run. We should find a way to do this in the background after the Use: URL has already been printed to the screen. So we perform this post flight check and then print out a post-flight error message if we learn something. Also skip this if
--fast
.Add in "diagnostics" button on the UD (next to documentation). This will load a page in the UD to perform browser->server and browser->agent specific tests. We should use this as a chance to detect if websockets work, if there are user | firewall issues, and whether the setting of CHE_DOCKER_IP_EXTERNAL is properly configured. You could imagine a series of tests that a user can run from within the browser and each test shows success or failure. This does not have to be nicely formatted - as it will be uncommon. For each failure condition, we should have helpful error message indicating what to do to resolve it
The text was updated successfully, but these errors were encountered: