Hide Forgot
Created attachment 1121170 [details] UI blocked Description of problem: When an ovirt admin attempts to execute a long running storage operation such as adding a new domain or activate an existing large storage domain, the admin user is blocked for up to 2.5 - 3.5 minutes by a spinner in a dialog box. Version-Release number of selected component (if applicable): How reproducible: Very Steps to Reproduce: 1. Create a large data ISCSI SD of multiple luns (tested with 7, 16, and 40+) 2. Click Attach from Web UI 3. User is blocked from 2-4+ mins Actual results: User is blocked from 2-4+ mins Expected results: That the operation occur in the background and the admin can continue to browse/use the web admin. Additional info:
Marking it as [high] from UX/usability perspective, obviously if you wait the operation will complete, adjust severity as necessary.
Isn't this just a specific case of bug 1259353?
Not sure since the problem in bug 1259353 is in the opening of the dialog and here it's in the saving, might be the same since in the other bug it's when editing the domain. In any way further investigation is needed so I keep this one open
This has been this dialog's behavior since forever. If we're still investing in the current webadmin it's worth fixing, but it's not a good fit for a z-stream.
Can you update with latest findings in logs (from your recent 4.1 tests)?
I'm quite sure this isn't the dialog or the UI but the engine command itself. What the 'add storage' is doing specifically is to wait till AddStorageServerConnectionCommand is done, because the behaviour is that if the connection is failing (can't connect to the host or any other reason) the dialog remains presented, and letting you amend the path in case it is wrong etc So the responsiveness here is bounded to how fast the engine will perform the connect command (can be also other things like db latency and so) So we have a tradeoff: catch execution failures and leave the dialog in place to prevent retyping all details again, against quick dialog dismiss and let the user track the succeed/fail using the event tab
ping
I have tested the bug under 4.1 build 4 with SD with 10 luns, the symptoms does not reproduced, the spinner takes about 25 seconds and the UI is not blocked - can close the spinner and continue working. Adding the relevant logs.