Description of problem: We could not see anything when first login to VM portal. But, we can list the VMs after pressing refresh button. Version-Release number of selected component (if applicable): ovirt-engine-4.2.6 How reproducible: 100% Steps to Reproduce: 1. Login to VM portal (We will see nothing). 2. Now, press 'Refresh button. 3. Now we can see all VMs associated with the user. Actual results: VM portal does not show any VM associated with a user after first login. Expected results: VM portal should show all VMs associated with a user after first login itlsef. Additional info:
Are you using group permissions?
likely duplicate of bug 1624219
No, there aren't any group permissions. This happens when a user with 'UserRole' permission logs in.
Ok, I see. Then please add engine.log, and describe the exact user's permissions granted on VM/Cluster/DC/System
similar investigation as in https://bugzilla.redhat.com/show_bug.cgi?id=1624219#c7 would be helpful (just with vms instead of vmpools)
(In reply to Michal Skrivanek from comment #5) > similar investigation as in > https://bugzilla.redhat.com/show_bug.cgi?id=1624219#c7 would be helpful > (just with vms instead of vmpools) Done, it could be an API bug although I'm surprised no one else has reported something like this. @Martin can you assist? on brq I have a test user t1 with 3 vms, UserRole added to them. curl -sS -k -u"t1@internal:redhat" -H"Accept: application/json" "https://brq/ovirt-engine/api/vms;max=2?search=page%201" --> doesn't work, returns {} curl -sS -k -u"t1@internal:redhat" -H"Accept: application/json" "https://brq/ovirt-engine/api/vms;max=2?search=SORTBY%20NAME%20ASC%20page%201" --> works, returns 2 vms a SORTBY shouldn't affect the count here
you can't use REST API in that naive way. REST API doesn't support search and filter with limit (max/paging) at the same time. There's a special dedicated combination which works - the latter one in previous example. Nothing else will work, and it's not going to get fixed according to https://bugzilla.redhat.com/show_bug.cgi?id=1534607#c6
Scott, the only difference I see in fetching the data initially and when hitting refresh is that on login we do: api/vms/;max=8?search=SORTBY NAME ASC page 1 api/vms/;max=8?search=SORTBY NAME ASC page 2 and so on until we get empty response that makes sense. What doesn't make sense we increase the numbers for vmpools too, but it's in sync with VMs, so e.g. when tehre are 50 pages of VMs and just 1 pool we query vmpools 50 times. What also doesn't make sense that after we go through all the pages (when not scrolling down - wasn't it supposed to load the additional pages only when you scroll?) we fetch the total number anyway during the internal timer refresh, in my case: api/vms/;max=344?search=SORTBY NAME ASC and same for pools. Is that intentional? and on button refresh we do: api/vms/;max=8?search=SORTBY NAME ASC&follow=cdroms,sessions,disk_attachments.disk,graphics_consoles,nics,snapshots,statistics,permissions.role btw that's 3MB on my setup, and it takes a fairly long time.
(In reply to Michal Skrivanek from comment #13) > Scott, the only difference I see in fetching the data initially and when > hitting refresh is that on login we do: > api/vms/;max=8?search=SORTBY NAME ASC page 1 > api/vms/;max=8?search=SORTBY NAME ASC page 2 > and so on until we get empty response > that makes sense. What doesn't make sense we increase the numbers for > vmpools too, but it's in sync with VMs, so e.g. when tehre are 50 pages of > VMs and just 1 pool we query vmpools 50 times. Yeah that's not right. > What also doesn't make sense that after we go through all the pages (when > not scrolling down - wasn't it supposed to load the additional pages only > when you scroll?) we fetch the total number anyway during the internal timer > refresh, in my case: > api/vms/;max=344?search=SORTBY NAME ASC > and same for pools. Is that intentional? > I'm not sure there. The InfiniteScroller component triggers the paged fetching supposedly as the user scrolls down. The user's "page" __should__ be stored in redux and __should__ be reused in the refresh (auto or manual). > > and on button refresh we do: > api/vms/;max=8?search=SORTBY NAME > ASC&follow=cdroms,sessions,disk_attachments.disk,graphics_consoles,nics, > snapshots,statistics,permissions.role > btw that's 3MB on my setup, and it takes a fairly long time. Like you mentioned, the auto and manual refreshed just grab everything. I remember some TODO comments in there for awhile now saying it should be a paged fetch. All that said, the main issue in this BZ is the paged fetch and the full fetch appear to use different permission calcs on the service side. If we get that fixed, we can fix the fetches to all consistently fetch pages and have VMs and Pools count pages on their own. I will check github issues to see if we have those changes logged...
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.