Fix the notebook status when stopping a server

[sdsc-org]

The notebook server status continues to show "Ready" for some time after the user deletes it.

[lorenzo-cavazzi]

Currently, when stopping a running notebook, the status button changes to Pending for a few instants, then back to Ready for a few seconds, and finally back to Pending for a short moment, sometimes not enough to be shown to the user before the row disappears.

The problem is that the /servers endpoint from the notebook service returns "Running" status for a while after the users invoke the DELETE api. Since the response from the API takes a few seconds and after that the status is Pending, a possible solution is to wait for it, leaving the server status to Ready but notifying the user that the required action is still pending -- maybe a popup or something else preventing the user to do other actions in the meanwhile.

[ciyer]

I would prefer not to have a popup. I thought there was an issue in renku-notebooks to fix this behavior, but I do not see it. My preferred solution is to delay the first request so that we don't get the false response, though fixed the problem at the source would be best.

[lorenzo-cavazzi]

At the moment the UI modifies the status of the server to "pending" immediately after invoking the stop API without waiting for the response since it takes a few seconds and we wanted to give immediate feedback to the user. It used to work well with the previous version of the APIs, but now the k8 status is used and there is a misalignment with the /servers response for a few seconds.

Technically, when the response from the delete API comes a few seconds later, the status of the server is pending. There isn't a real bug in the current backend implementation, but since rancher can detect the changing pod status almost immediately after the delete command, there must be a way to get this information from the backend, but it appears not to be trivial to get it.

On the frontend, I thought that using a modal could be a way to wait while the stop command has gone through.
Another way to address this could be to stop query the "/servers" endpoint for a few seconds until the response comes back, then start again.
On Friday I implemented a simple solution using the modal, I'll create a PR to share it since it's almost done, but of course we can choose another way to address this.