Bug 1771793 - VM Portal crashes in what appears to be a permission related problem.
Summary: VM Portal crashes in what appears to be a permission related problem.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-web-ui
Version: 4.3.6
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ovirt-4.4.0
: ---
Assignee: Scott Dickerson
QA Contact: Pavel Novotny
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-13 01:05 UTC by Germano Veit Michel
Modified: 2023-10-06 18:46 UTC (History)
4 users (show)

Fixed In Version: ovirt-web-ui-1.6.1-1
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-08-04 13:21:16 UTC
oVirt Team: UX
Target Upstream Version:
Embargoed:
lsvaty: testing_plan_complete-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github oVirt ovirt-web-ui issues 1128 0 None closed Main page crash after taking pool VM 2020-07-11 19:12:19 UTC
Github oVirt ovirt-web-ui pull 1174 0 None closed Fix Pool handling and refactor VM loading 2020-07-11 19:12:19 UTC
Red Hat Knowledge Base (Solution) 4886781 0 None None None 2020-03-09 05:32:34 UTC
Red Hat Product Errata RHSA-2020:3247 0 None None None 2020-08-04 13:21:37 UTC

Description Germano Veit Michel 2019-11-13 01:05:49 UTC
Description of problem:

Opening the VM portal briefly shows 8 VMs (most likely the first page), then crashes.

Restoring the database and navigating to VM portal is enough to reproduce it. 

I tried to copy most permissions and create a VM Pool similar to the customer in our labs, but did not reproduce on same versions.

 debug  http GET[53] -> url: "/ovirt-engine/api/vms/;max=8?search=SORTBY NAME ASC page 3&follow=graphics_consoles", headers: {"Accept":"application/json","Authorization":"*****","Accept-Language":"en_US","Filter":false} transport.js:73:10
 debug  Reducing action: {"type":"PERSIST_STATE"} utils.js:47:14
 debug  persistStateToLocalStorage() called storage.js:18:10
 debug  Reducing action: {"type":"UPDATE_VMPOOLS_COUNT"} utils.js:47:14
 warn  No translation for enum item "VmStatus.undefined" found. index.js:177:10
 error  TypeError: "n is undefined"
    default index.js:323
    Redux 8
    qt react-dom.production.min.js:132
    Dn react-dom.production.min.js:167
    Rn react-dom.production.min.js:180
    wr react-dom.production.min.js:232
    Sr react-dom.production.min.js:233
    zr react-dom.production.min.js:249
    Yr react-dom.production.min.js:248
    jr react-dom.production.min.js:245
    Or react-dom.production.min.js:243
    enqueueSetState react-dom.production.min.js:130
    setState React
    Redux 12
    v middleware.js:25
    Redux 14
    jQuery 2

That index.js:323 seems to be this:

export default withRouter(
  connect(
    (state, { vm }) => ({
      isEditable: vm.get('canUserEditVm') && state.clusters.find(cluster => cluster.get('canUserUseCluster')) !== undefined,
      config: state.config,
    }),

But this does not seem to have changed for a long time.

Also, the customer suggests this was working before the latest upgrade.

Version-Release number of selected component (if applicable):
ovirt-web-ui-1.6.0-1.el7ev.noarch
rhvm-4.3.6.7-0.1.el7.noarch

How reproducible:
Only with customer Database so far

Comment 4 Sharon Gratch 2019-11-14 10:50:17 UTC
Please note that this issue is reproduced on ovirt-web-ui master as well.

Comment 9 Scott Dickerson 2019-12-02 21:32:22 UTC
Looks to be the same issue as https://github.com/oVirt/ovirt-web-ui/issues/1128.

Comment 16 Pete Ditmars 2020-03-02 18:40:36 UTC
Hi,

I don't have an exact location in the code where this is going wrong, but I can share that in our environment the key for reproducing this is that if at least one VM in the pool is in a Up/Running state when you log into the VM portal you get this behavior where the VM Portal screen briefly displays all VMs in the pool and then you get the "Sorry, VM Portal is currently having some issues" screen.  If all VMs in all pools are not Up/Running, you can log in and see the VMs in the VM Portal.  

We haven't done anything with adjusting permissions that I'm aware of.

If you log into the portal with all VMs in a given pool in a down/Off state, things work fine.
If there are VMs that are not in a pool in an Up/Running state, things still work fine
If you Start a VM that is in a pool, it goes to a Running state in the portal and things still work fine.
If you refresh the portal screen after starting a VM, you will get the error behavior.
If you log out and try go log back in, you see all the VMs for an instant and then get the error behavior.

I hope this helps narrow down the issue.

Thanks,

Pete

Comment 17 Pete Ditmars 2020-03-06 18:38:47 UTC
And, as noted in https://github.com/oVirt/ovirt-web-ui/issues/1128 this only occurs if the user has SuperUser privilege.

If you remove SuperUser privilege, the user can log into the portal and view all the VMs in the pool even when there is one or more in the Running state.

Comment 18 Michal Skrivanek 2020-03-11 11:44:11 UTC
too late for a backport, still don't have a solution, dropping zstream request

Comment 21 Pavel Novotny 2020-04-07 21:22:21 UTC
Verified in
ovirt-engine-4.4.0-0.31.master.el8ev.noarch
ovirt-web-ui-1.6.1-0.20200228.git5b3b4e0.el8ev.noarch

VM Portal no longer crashes when a SuperUser takes or starts a pool VM or displays/reloads VM list with a running pool VM.

Comment 22 Pavel Novotny 2020-04-07 21:29:28 UTC
Tested in browsers: Firefox 74.0.1, Chromium 80

Comment 26 errata-xmlrpc 2020-08-04 13:21:16 UTC
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 (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), 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/RHSA-2020:3247


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