Bug 1480877 - [BLOCKED on bug 1534607] VM Portal never never displays VMs for users with administrative permissions [NEEDINFO]
[BLOCKED on bug 1534607] VM Portal never never displays VMs for users with ad...
Status: ON_QA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-web-ui (Show other bugs)
4.1.4
All Linux
unspecified Severity high
: ovirt-4.2.2
: ---
Assigned To: Marek Libra
Lucie Leistnerova
: Reopened
Depends On: 1534607 1481212
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-12 12:05 EDT by Allan Voss
Modified: 2018-01-22 08:08 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-09-19 03:16:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
michal.skrivanek: needinfo? (avoss)


Attachments (Terms of Use)
Screenshot demonstrating perpetual Loading screen for admin users of VM portal (38.72 KB, image/png)
2017-08-12 12:05 EDT, Allan Voss
no flags Details
requested API output (8.49 KB, application/xml)
2017-11-22 14:02 EST, Allan Voss
no flags Details

  None (edit)
Description Allan Voss 2017-08-12 12:05:38 EDT
Created attachment 1312460 [details]
Screenshot demonstrating perpetual Loading screen for admin users of VM portal

Description of problem:

When logging in as a user with administrative permissions, the portal just says "Loading ..." and never displays any VMs. Normal users do not have this issue, but all users with admin permissions do. 

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

RHV 4.1

How reproducible:
Very

Steps to Reproduce:
1. Create VMs
2. Create user with admin permissions
3. log in as user with admin permissions

Actual results:
Perpetual "Loading...." screen

Expected results:
Display of available VMs
Comment 1 Michal Skrivanek 2017-08-13 03:03:43 EDT
VM portal was introduced as a tech preview in 4.1.4, you have 4.1.2?
Comment 2 Tomas Jelinek 2017-08-14 04:01:50 EDT
This is caused by the fact that the admin user does not have any filtering so the response is much bigger and the parsing/getting the response from api takes long time.

This is fixed by pagination. The patch is merged upstream and will get to ovirt-web-ui 1.2.1 which will go out with ovirt 4.1.6
Comment 4 Lucie Leistnerova 2017-08-28 08:42:19 EDT
In VM portal is loaded only few first rows of VMs and when scrolling down new VMs are loaded. So the VM grid is quickly displayed even if 1000 VMs should be loaded.

verified in ovirt-engine-4.1.6-0.1.el7.noarch with ovirt-web-ui-1.2.1-1.el7ev.noarch
Comment 10 errata-xmlrpc 2017-09-19 03:16:38 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2744
Comment 12 Yaniv Kaul 2017-10-26 09:40:04 EDT
Tomas, is this being looked at?
Comment 20 Marek Libra 2017-11-21 05:50:52 EST
Should be fixed by upstream patch: https://github.com/oVirt/ovirt-web-ui/pull/430
Comment 21 Allan Voss 2017-11-22 14:02 EST
Created attachment 1357753 [details]
requested API output
Comment 22 Michal Skrivanek 2017-11-23 03:32:46 EST
Hi Allan, does it reproduce for you? Can you try out the fix posted in comment #20?
Comment 24 Michal Skrivanek 2017-12-21 10:44:10 EST
(In reply to Michal Skrivanek from comment #22)
> Hi Allan, does it reproduce for you? Can you try out the fix posted in
> comment #20?

fix is in ovirt-web-ui-1.3.3-1, so the current oVirt 4.2.0 GA should have it, but we do not have any reproducer yet, so verification might not be possible. Deferring this tough call to QE
Comment 25 Lucie Leistnerova 2018-01-19 04:54:52 EST
For SuperUser the VMs are displayed correctly, but I can't now verify VMs under UserRole because backend api doesn't work correctly. See blocking Bug 1534607.

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