Bug 1284584 - NPE when attempting to edit a Cluster that doesn't have a management network associated with it
NPE when attempting to edit a Cluster that doesn't have a management network ...
Status: CLOSED DUPLICATE of bug 1279955
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.6.0
All Linux
high Severity high
: ovirt-3.6.2
: ---
Assigned To: Yevgeny Zaspitsky
network
:
Depends On:
Blocks: RHEV_36_HTB
  Show dependency treegraph
 
Reported: 2015-11-23 10:53 EST by Julio Entrena Perez
Modified: 2016-11-14 23:34 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-10 09:56:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Julio Entrena Perez 2015-11-23 10:53:17 EST
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 11:12:51 EST
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 02:58:50 EST
Sounds like a dup to me, but I could not find the original bug.
Comment 3 Julio Entrena Perez 2015-11-25 09:17:50 EST
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 12:01:45 EST
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 13:59:25 EST
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 14:05:55 EST
(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 14:18:15 EST
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 04:57:05 EST
Yevgeni, is this the same bug solved by https://gerrit.ovirt.org/#/c/50038/ ?
Comment 16 Yevgeny Zaspitsky 2015-12-09 16:35:14 EST
IMO is same as https://bugzilla.redhat.com/show_bug.cgi?id=1279955
Comment 17 Yevgeny Zaspitsky 2015-12-10 08:10:15 EST
reinstate needinfo on pcuzner@redhat.com
Comment 18 Dan Kenigsberg 2015-12-10 09:56:58 EST
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-14 23:34:43 EST
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.