Bug 858166 - PRD34 - [RFE] webadmin - centralized refreshing logic
Summary: PRD34 - [RFE] webadmin - centralized refreshing logic
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.4.0
Assignee: Alexander Wels
QA Contact: Pavel Stehlik
URL:
Whiteboard: ux
Depends On:
Blocks: 879662 1049996
TreeView+ depends on / blocked
 
Reported: 2012-09-18 08:41 UTC by Pavel Stehlik
Modified: 2019-04-28 09:54 UTC (History)
13 users (show)

Fixed In Version: ovirt-3.4.0-alpha1
Doc Type: Enhancement
Doc Text:
Previously, making a change to an object in the Administration Portal and attempting to perform subsequent actions on that object or related objects would result in an error under certain conditions. This was caused by the logic used to refresh objects in the Administration Portal, whereby objects would only be fully refreshed after reaching the next refresh interval following a change. Now, the logic used to refresh objects has been revised so that objects are fully refreshed immediately following an action, making it possible to perform subsequent actions on those objects without issue.
Clone Of:
: 1049996 (view as bug list)
Environment:
Last Closed: 2014-06-12 14:04:10 UTC
oVirt Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2014:0506 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Virtualization Manager 3.4.0 update 2014-06-09 18:55:38 UTC
oVirt gerrit 21057 0 None None None Never

Description Pavel Stehlik 2012-09-18 08:41:55 UTC
Description of problem:
 Nowadays I can clearly see in Events (below the main RHEVM screen) the task/event is completed, however user can't operate with affected entities accordingly.
 Example:
Put host to maintenance & try to edit its DC/cluster. You'll see the action is finished & you click Edit button, however you can't change cluster not even refresh of gui (as Edit Host window is not refreshed). You'll need to close Edit window & open it again.
This is same with any other entities (VMs/Pools....)
It's inconvenient to wait 5+s after each operation 

Version-Release number of selected component (if applicable):
siXYZ

How reproducible:
100%

Steps to Reproduce:
1. try any task 
2.
3.
  
Actual results:
Delay between information & real possibility of change.

Expected results:
Synchronized refresh for these operations.

Additional info:

Comment 1 David Jaša 2012-10-16 14:57:02 UTC
I noticed the same issue when working with VM snapshots (e.g. seeing that the commit was finished but the VM is not able to start for another 5 seconds) and it's really annoying - therefore I propose to to fix it in 3.1.

Comment 9 Andrew Cathrow 2012-10-22 19:49:20 UTC
Setting placeholder for 3.2 and (potential) .z

Comment 10 Vojtech Szocs 2012-11-02 15:36:20 UTC
From code perspective, the refresh logic in 3.1 (GWT technology) is the same as in 3.0 (WPF technology). This is because common UI logic (also known as "uicommon") was re-used in 3.1 by converting C# code into Java.

By design, different parts of GUI are refreshed independently from other parts. This results in multiple HTTP requests against the backend, as each GUI component tries to fetch its "own" data. If one GUI component has refresh rate X and another component has refresh rate Y, when X != Y, GUI as a whole is generally "not in sync" with regard to current data.

In 3.0 (WPF technology), communication between GUI and backend was synchronous. In 3.1 (GWT technology), communication between GUI and backend is asynchronous. This fact makes the refresh logic problem more visible.

Short-term solution: at certain moments (e.g. closing a dialog with OK button, clicking action button in a data grid), enforce all GUI components to refresh their data immediately. This way the GUI will be "in sync" with regard to current data at certain key moments during the runtime.

Long-term solution: re-write refresh logic, potentially optimizing the number of HTTP requests against the backend.

Comment 12 Sandro Bonazzola 2014-01-14 08:43:03 UTC
ovirt 3.4.0 alpha has been released

Comment 20 Itamar Heim 2014-06-12 14:04:10 UTC
Closing as part of 3.4.0


Note You need to log in before you can comment on or make changes to this bug.