Bug 858166 - PRD34 - [RFE] webadmin - centralized refreshing logic
PRD34 - [RFE] webadmin - centralized refreshing logic
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity high
: ---
: 3.4.0
Assigned To: Alexander Wels
Pavel Stehlik
ux
: FutureFeature
Depends On:
Blocks: 879662 1049996
  Show dependency treegraph
 
Reported: 2012-09-18 04:41 EDT by Pavel Stehlik
Modified: 2014-09-09 15:37 EDT (History)
14 users (show)

See Also:
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.
Story Points: ---
Clone Of:
: 1049996 (view as bug list)
Environment:
Last Closed: 2014-06-12 10:04:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 21057 None None None Never
Red Hat Product Errata RHSA-2014:0506 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Virtualization Manager 3.4.0 update 2014-06-09 14:55:38 EDT

  None (edit)
Description Pavel Stehlik 2012-09-18 04:41:55 EDT
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 10:57:02 EDT
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 15:49:20 EDT
Setting placeholder for 3.2 and (potential) .z
Comment 10 vszocs 2012-11-02 11:36:20 EDT
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 03:43:03 EST
ovirt 3.4.0 alpha has been released
Comment 20 Itamar Heim 2014-06-12 10:04:10 EDT
Closing as part of 3.4.0

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