Created attachment 1228476 [details] error Description of problem: I have installed ovirt-engine-webadmin-portal-debuginfo-4.0.6.1-0.1.el7ev.noarch.rpm with engine 4.0.6.1-0.1.el7ev. Then I upgraded to engine 4.0.6.2-0.1.el7ev # yum update ovirt-engine-setup ovirt-engine-setup-plugin-websocket-proxy # engine-setup ... all seemed OK, no unusual errors in log files. After some work with webadmin UI dialog error occurs: java.lang.reflect.InvocationTargetException. Restart or rerun of engine-setup didn't help. When I upgraded ovirt-engine-webadmin-portal-debuginfo from 4.0.6.1-0.1.el7ev to 4.0.6.2-0.1.el7ev and run engine-setup everything was OK. How reproducible: with combination ovirt-engine-webadmin-portal-debuginfo-4.0.6.1-0.1.el7ev and engine 4.0.6.2-0.1.el7ev Actual results: error displayed, see attachment Expected results: no error, engine-setup should upgrade ovirt-engine-webadmin-portal-debuginfo if installed Additional info: If I kill all the dialogs with error I can go along the engine tabs except of VM tab, then the error was back.
lost in all the versions Version-Release number of selected component (if applicable): ovirt-engine-setup-4.0.6.2-0.1.el7ev.noarch
It should be easy to add to the spec file, for all the debuginfo packages: Requires: %{name} = %{version}-%{release} But perhaps there is a reason why we don't do this. Alexander?
I see this was already discussed in [1], when adding these packages. Adding Vojtech, not sure who should know best. [1] https://gerrit.ovirt.org/#/c/36655/
So the reason we don't install this by default is because the symbol maps are fairly large ~80M or so. If we don't mind this, then we should add the requires.
(In reply to Alexander Wels from comment #4) > So the reason we don't install this by default is because the symbol maps > are fairly large ~80M or so. If we don't mind this, then we should add the > requires. No, that wasn't the question. The question was if we need to be able to install the debuginfo packages without the engine. If the debuginfo packages require engine of same version, you can still install the engine without them, but when you do have them, and update the engine, yum should update them too. BTW, doing this will lead to a new bug - 'yum update' will then fail, unless we versionlock the debuginfo packages. Perhaps we should indeed versionlock them as well. Yuck.
Yes we should version lock the debug package with the engine. The debug symbols must match the engine version, and no we don't need to install them without the engine, as they as information about the GWT permutations of that specific engine version.
(In reply to Alexander Wels from comment #6) > Yes we should version lock the debug package with the engine. The debug > symbols must match the engine version, and no we don't need to install them > without the engine, as they as information about the GWT permutations of > that specific engine version. Ok, this settle it. Let's add the missing require.
Just to add a note, I don't think the debuginfo is the source of the exceptions originally reported by this bz. A restart of the engine temporarily makes the exceptions go away but they return shortly after that. I also have an upstream community member reporting the same issue. I have been update to determine the source as of yet.
Wouldn't be enough to add this package into versionlock.list ? tl;dr the code but doesn't it update all rpms in versionlock.list?
(In reply to Alexander Wels from comment #8) > Just to add a note, I don't think the debuginfo is the source of the > exceptions originally reported by this bz. A restart of the engine > temporarily makes the exceptions go away but they return shortly after that. > I also have an upstream community member reporting the same issue. I have > been update to determine the source as of yet. I would agree, I don't have debuginfo packages and my Admin Portal shows UI issue mentioned by others.
Alexander, Jiri... you are right. I came today and the error is back, but I have the newest debuginfo packages. Can't find error anywhere in logs. I will investigate it more. Still I think that when I have installed debuginfo engine-setup should update it.
in response of https://myengine/ovirt-engine/webadmin/xsrf my browser says is bad JSON, could that be it? //OK[2,1,["com.google.gwt.user.client.rpc.XsrfToken/4254043109","CC08CF9D159582AA7B9B53F70281A2D3CE102E3FCD693C3E769474C367752ADC"],0,7] after that this script is called https://myengine/ovirt-engine/webadmin/GenericApiGWTService function L1e$(_0,_1){_0.g=_1;return _0}throw L1e$(new (ELf(Srb)),"java.lang.reflect.InvocationTargetException"); and this two scripts are called when the error appears. I have one running VM on the engine. When I stop it error don't show. It happens only in VM tab, VM showed from Host tab is OK.
AFAIU the debuginfo has nothing to do with the problem. Feel free to add the package by default, but it is not needed, so also feel free to just close this bug. The exception is being handled in bug 1402401
(In reply to Michal Skrivanek from comment #13) > AFAIU the debuginfo has nothing to do with the problem. Feel free to add the > package by default, That wasn't the question - the question was whether having non-compatible engine and debuginfo packages can lead to problems and/or should be prevented. > but it is not needed, so also feel free to just close > this bug. > The exception is being handled in bug 1402401 Thanks. Closing for now. Please reopen if indeed it's a bug.
Btw note this is a serious problem for several testers, and at least one community member. I believe the problem lies somewhere on the back-end when the UI makes a query, which causes an exception. This exception is then eaten AND NOT logged, which then returns the InvocationTargetException to the UI. The UI thinks hmm some exception occured this usually means my XSRF token is bad, lets get a new one and try again. Which then repeats a bunch of times. Something in 4.0.6-2 or 3 is causing this, the UI has nothing to do with it.
(In reply to Alexander Wels from comment #15) > Btw note this is a serious problem for several testers, and at least one > community member. I believe the problem lies somewhere on the back-end when > the UI makes a query, which causes an exception. This exception is then > eaten AND NOT logged, which then returns the InvocationTargetException to > the UI. The UI thinks hmm some exception occured this usually means my XSRF > token is bad, lets get a new one and try again. Which then repeats a bunch > of times. > > Something in 4.0.6-2 or 3 is causing this, the UI has nothing to do with it. Sorry, I do not fully understand. So it's a bug, or not? A bug somewhere else that manifests when they differ?
(In reply to Yedidyah Bar David from comment #16) > (In reply to Alexander Wels from comment #15) > > Btw note this is a serious problem for several testers, and at least one > > community member. I believe the problem lies somewhere on the back-end when > > the UI makes a query, which causes an exception. This exception is then > > eaten AND NOT logged, which then returns the InvocationTargetException to > > the UI. The UI thinks hmm some exception occured this usually means my XSRF > > token is bad, lets get a new one and try again. Which then repeats a bunch > > of times. > > > > Something in 4.0.6-2 or 3 is causing this, the UI has nothing to do with it. > > Sorry, I do not fully understand. So it's a bug, or not? A bug somewhere > else that manifests when they differ? So I talked to Oved, and this (the debug info causing a problem) is NOT a bug, however BZ1402401 causes the TargetInvocationException to happen, and that is a bug.
I admit that the problem of the exception was elsewhere. But still I have to upgrade packages of debuginfo manually. So there is no easy way how to check that the package is installed and upgrade it with engine-setup?
I think there is a way to check, but I don't know the mechanism. Sandro knows though.
Of course there is a way, but in general we only update packages that must be updated for the engine to work well. Our upgrade instructions do say to run 'yum update' after engine-setup finishes.
Update: the other bug 1402401 (accessing VM tab triggers error dialog) is now MODIFIED. As for this bug: > the question was whether having non-compatible engine and debuginfo packages can lead to problems and/or should be prevented Yes, having non-compatible Engine vs. debuginfo packages *will* lead to problems. > Thanks. Closing for now. Please reopen if indeed it's a bug. Re-opening.. We should version-lock debuginfo packages: when those are installed (optional by default), their version *must* be the same as Engine version.
A similar issue now came up on [1]. Thinking about this, I am not sure what we'll do. We can easily add to the debuginfo packages: Requires: %{name} = %{version}-%{release} This will (hopefully, didn't check) solve the flow in [1]. It might break 'yum update' later on, if the package is not version-locked. But since it's not mandatory, nothing will version-lock it if it's installed manually by yum. So a next engine-setup can version-lock it, which will probably help future yum updates, but not first one after yum install *debuginfo. [1] http://lists.ovirt.org/pipermail/users/2017-February/079523.html
about yum update error messages related to version locking: debug packages are not meant to be installed on any production environment other than for debugging purpose. Once the debug is finished they need to be removed.
(In reply to Yedidyah Bar David from comment #22) > We can easily add to the debuginfo packages: > > Requires: %{name} = %{version}-%{release} Given that `debuginfo` pkgs are yum installed manually on demand, I think this is the most correct solution. When a `debuginfo` pkg is yum installed, we must ensure the user gets the right version, so RPM Requires is a good fit here. > It might break 'yum update' later on, if the package is not version-locked. > But since it's not mandatory, nothing will version-lock it if it's installed > manually by yum. If we're able to detect optional pkgs when `engine-setup` is run, and version-lock them, we can do that. Otherwise, let users handle the `debuginfo` pkgs manually.
(In reply to vszocs from comment #24) > (In reply to Yedidyah Bar David from comment #22) > > We can easily add to the debuginfo packages: > > > > Requires: %{name} = %{version}-%{release} > > Given that `debuginfo` pkgs are yum installed manually on demand, I think > this is the most correct solution. When a `debuginfo` pkg is yum installed, > we must ensure the user gets the right version, so RPM Requires is a good > fit here. This is what has been implemented > > > It might break 'yum update' later on, if the package is not version-locked. > > But since it's not mandatory, nothing will version-lock it if it's installed > > manually by yum. > > If we're able to detect optional pkgs when `engine-setup` is run, and > version-lock them, we can do that. Otherwise, let users handle the > `debuginfo` pkgs manually. See comment #23
Debuginfo packages requires appropriate portal package, so 'yum update' fails without running engine-setup first. It works for me together with documentation 4.1 that says that 'yum update' after upgrade should be done. verified in ovirt-engine-4.1.1.5-0.1.el7.noarch