search

rancher / dashboard

The Rancher UI
https://rancher.com
Apache License 2.0
454 stars 257 forks source link

Retain the Kubectl/log shells on page reload #11396

Open valaparthvi opened 2 months ago

valaparthvi commented 2 months ago

Is your feature request related to a problem? Please describe.

As a QA, while I am testing things, I like to keep the operator logs open so that I can monitor activities triggered during test. I specifically work on hosted providers, so I follow gke/eks/aks operator logs while working with the clusters, many a times I need to reload the page because UI is not fast enough to give live status of the clusters, but reloading the page mean I lose the shells that were displaying logs, and I have to go to the apps list again and restart the logs shell.

Describe the solution you'd like

Retain the terminal shells on page reload.

Describe alternatives you've considered

Additional context

Screencast from 07-09-2024 06:00:19 PM.webm

richard-cox commented 2 months ago

We should make this optional, as some users will want a fresh start on refresh.

I'm also concerned about the need to refresh. In this feature the UI is a simple shim over what is provided over websocket, and it's probably the case the UI isn't receiving this information. @valaparthvi when you say it does not keep up, are you saying there's 100s of lines a second, or there's lag between the actual server state and what's shown in the logs?

Would you also be able to provide steps to reproduce (just so everyone is clear which logs and where they were kicked off)?

valaparthvi commented 2 months ago

I usually don't wait to note the delay, I refresh if the cluster status Provisioning or Updating backgroud is red and it does not immediately report an error, for e.g in the screen cast here:

I'm also concerned about the need to refresh. In this feature the UI is a simple shim over what is provided over websocket, and it's probably the case the UI isn't receiving this information.

You are right, it is a valid concern. I believe the time to refresh is case based, sometimes I have noticed the error appears almost as soon as Provisioning turns red. for e.g. in the case where AKS nodepool name is longer than 12 characters, but in some cases like below, it may take a few minutes or even a reload for the error to appear.

I am not sure about exact steps to reproduce, but I noticed it while creating AKS with invalid SSH key, perhaps that might work.

  1. Create AKS cluster with an invalid/malformed ssh key.
  2. Hit save and wait for the Provisioning to turn red. IT waited at least half a minute before reloading the page to see why it was red and what the error was. Screencast from 07-10-2024 08:43:00 PM.webm