Slow response in the UI

[webteam-app]

Bug originally filed by woutervb at https://bugs.launchpad.net/bugs/1818004

On a high latency link the response of the UI is dramatic. That is it can take up to a minute, or longer to see the result of an action.

Specifically while editing partition on a host with 12 disks, it is hard not to make a mistake.
Renaming a disk takes + 30 seconds to complete, and the interface suggests that it is doing things in the background so the next disk could be renamed. But then all of a sudden multiple questions pop-up asking for confirmation that the disk really should be renamed.

On the interface page, it takes nearly a minute to see the result of the deletion of a bond and the interfaces being visible again, in order to be able to select them and re-create a bond.

[squidsoup]

There's nothing actionable here, as we can't do anything about network latency.

[anthonydillon]

This issue is related to a lack of action feedback on tasks. For example, If you delete a bond and it takes over a minute for the action to complete we should display an action is in process.

[squidsoup]

This issue is related to a lack of action feedback on tasks. For example, If you delete a bond and it takes over a minute for the action to complete we should display an action is in process.

The lack of feedback is a problem, but that's not the issue the user is complaining about. They're talking about workflow issues due to latency. This won't be addressed with action feedback.

The problem here is that the user wants to perform multiple dependant actions, and has to wait for each to complete in turn, which takes time. The UI would have to be completely re-engineered (and probably the backend) for both storage and network configuration to address this problem. Essentially we need the user to specify the ultimate desired state of their network and storage configuration, which the backend can resolve, rather than performing each step incrementally (first add an interface, wait, configure a bond, wait etc.).

I'll reopen this, but there's no simple path to address this problem.

[cassiocassio]

is it possible to separate out the challenges?

• improvements to feedback mechanisms, where they need to be blocking

• workflows that need confirmation to be client-side, before sending the request?

• speeding up things that do take 30s, but shoulnd't?

• providing better feedback for things that must take 30s, so user's don't think it's broken, but will complete eventually

• [I'm sure @Caleb-Ellis did some of this] breaking that feedback into multiple steps - thanks for your click, request sent, request processing, % complete, etc

• for multiple actions that -can- be queued, being less modal with confirmation-steps that must happen later.

(I'm sure there's more)

The current version of storage might not be the place to retro-fit all of this.

[Caleb-Ellis]

We've been tackling both performance issues and perceived performance enhancements (i.e. spinners/loading state) over the past 2 years since this issue was created. Since nothing in this issue is directly actionable I'm closing it.