Bug 1284584 - NPE when attempting to edit a Cluster that doesn't have a management network associated with it
Summary: NPE when attempting to edit a Cluster that doesn't have a management network ...
Keywords:
Status: CLOSED DUPLICATE of bug 1279955
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.6.0
Hardware: All
OS: Linux
high
high
Target Milestone: ovirt-3.6.2
: ---
Assignee: Yevgeny Zaspitsky
QA Contact:
URL:
Whiteboard: network
Depends On:
Blocks: RHEV_36_HTB
TreeView+ depends on / blocked
 
Reported: 2015-11-23 15:53 UTC by Julio Entrena Perez
Modified: 2016-11-15 04:34 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-10 14:56:58 UTC
oVirt Team: Network
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Julio Entrena Perez 2015-11-23 15:53:17 UTC
Description of problem:
When attempting to increase the compatibility version of a cluster from 3.5 to 3.6, after pressing "OK" in the confirmation dialogue the spinning wheel displays and stays there "forever", operation never completes.

Version-Release number of selected component (if applicable):
rhevm-3.6.0.3-0.1.el6

How reproducible:
Always

Steps to Reproduce:
1. Edit the properties of a cluster at 3.5 compatibility version, select 3.6 and click OK.
2. Click OK in the confirmation dialogue.
3.

Actual results:
Spinning wheel on the "Edit Cluster" dialogue.
Operation does not complete.

Expected results:
Operation completes and cluster is at 3.6 compatibility version.

Additional info:
Nothing is logged in engine.log.

Comment 1 Julio Entrena Perez 2015-11-23 16:12:51 UTC
Developer Tools in Firefox reveals the following error:

Mon Nov 23 16:11:09 GMT+000 2015 
SEVERE: Uncaught exception: com.google.gwt.core.client.JavaScriptException: (TypeError) 
 __gwt$exception: <skipped>: f is undefined
	at Unknown.tFo(Unknown Source)
	at Unknown.sFo(Unknown Source)
	at Unknown.oGo(Unknown Source)
	at Unknown.SLn(Unknown Source)
	at Unknown.VLn(Unknown Source)
	at Unknown.MPn(Unknown Source)
	at Unknown.PPn(Unknown Source)
	at Unknown.sOn(Unknown Source)
	at Unknown.vOn(Unknown Source)
	at Unknown.WHe(Unknown Source)
	at Unknown.Puk(Unknown Source)
	at Unknown.k4(Unknown Source)
	at Unknown.D4(Unknown Source)
	at Unknown._uf/c.onreadystatechange<(Unknown Source)
	at Unknown.Yt(Unknown Source)
	at Unknown.au(Unknown Source)
	at Unknown._t/<(Unknown Source)
	at Unknown.anonymous(Unknown Source)
 0593B5FD9EB837819F3C5747FA3B157A.cache.html:23916:12153

Comment 2 Yaniv Kaul 2015-11-24 07:58:50 UTC
Sounds like a dup to me, but I could not find the original bug.

Comment 3 Julio Entrena Perez 2015-11-25 14:17:50 UTC
Actually the same seems to happen when editing _any_ property of the cluster (e.g. when setting the scheduling policy to evenly_distributed).

Comment 7 Einav Cohen 2015-11-25 17:01:45 UTC
posting here (what seems to be) the relevant portion of the client (javascript) log that contains the exception that is most likely responsible for this issue (provided by Paul):

...
SEVERE: Uncaught exception: com.google.gwt.core.client.JavaScriptException: (TypeError) 
 __gwt$exception: <skipped>: f is undefined
	at Unknown.tFo(Unknown Source)
	at Unknown.sFo(Unknown Source)
	at Unknown.oGo(Unknown Source)
	at Unknown.SLn(Unknown Source)
	at Unknown.VLn(Unknown Source)
	at Unknown.MPn(Unknown Source)
	at Unknown.PPn(Unknown Source)
	at Unknown.sOn(Unknown Source)
	at Unknown.vOn(Unknown Source)
	at Unknown.WHe(Unknown Source)
	at Unknown.Puk(Unknown Source)
	at Unknown.k4(Unknown Source)
	at Unknown.D4(Unknown Source)
	at Unknown._uf/c.onreadystatechange<(Unknown Source)
	at Unknown.Yt(Unknown Source)
	at Unknown.au(Unknown Source)
	at Unknown._t/<(Unknown Source)
	at Unknown.anonymous(Unknown Source)
...

@Alexander - by mapping the above to a non-obfuscated javascript, we should be able to find out what's wrong (contact Vojtech for assistance on that, if necessary). 
You can also access Julio's env in order to reproduce and further investigate. 

Thanks.

Comment 11 Alexander Wels 2015-12-01 18:59:25 UTC
Julio,

Can I get some information on how this environment was created? Was it an upgrade from a 3.5? Fresh install? There seem to be a few strange things I am noticing, namely a missing management network, and no 'default' data center. It will be helpful to know the process you took in case there is a problem there that accidentally removes the management network.

Comment 12 Julio Entrena Perez 2015-12-01 19:05:55 UTC
(In reply to Alexander Wels from comment #11)
> Julio,
> 
> Was it an upgrade from a 3.5?

Yes, it was an upgrade from 3.5.5 indeed.

The 'default' datacenter was manually deleted indeed.
Unfortunately I don't know why the existing network is not flagged as management, meaning I don't know if this was manually changed by any one or if it's a result of the upgrade process.
Still, imho the current behaviour (Javascript error) shouldn't happen in any case.

Comment 13 Einav Cohen 2015-12-01 19:18:15 UTC
moving BZ to the 'network' team - it seems like the NPE is a result of a missing management network or something similar; so networking flows should be investigated and fixed accordingly. 
feel free to contact Alexander for any details on his findings so far.

Comment 15 Dan Kenigsberg 2015-12-09 09:57:05 UTC
Yevgeni, is this the same bug solved by https://gerrit.ovirt.org/#/c/50038/ ?

Comment 16 Yevgeny Zaspitsky 2015-12-09 21:35:14 UTC
IMO is same as https://bugzilla.redhat.com/show_bug.cgi?id=1279955

Comment 17 Yevgeny Zaspitsky 2015-12-10 13:10:15 UTC
reinstate needinfo on pcuzner

Comment 18 Dan Kenigsberg 2015-12-10 14:56:58 UTC
rhev-3.6.0 ("beta1") has never claimed to support upgrade from 3.5.z.

Please try upgrading from 3.5 to a 3.6.1 build. If the bug prevails, please reopen it. However, the premise and the symptoms match those of the solved bug 1279955.

*** This bug has been marked as a duplicate of bug 1279955 ***

Comment 19 Paul Cuzner 2016-11-15 04:34:43 UTC
This is a cold case now - and likely resolved by now.


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