Bug 1119040 - Adding a new host fails on engine's logs
Summary: Adding a new host fails on engine's logs
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.5
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 3.6.0
Assignee: Mooli Tayer
QA Contact: Pavel Stehlik
URL:
Whiteboard: infra
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-13 13:49 UTC by Ori Gofen
Modified: 2016-05-26 01:48 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-19 08:14:27 UTC
oVirt Team: Infra


Attachments (Terms of Use)
vdsm+engine logs (526.71 KB, application/x-gzip)
2014-07-13 13:49 UTC, Ori Gofen
no flags Details

Description Ori Gofen 2014-07-13 13:49:39 UTC
Created attachment 917622 [details]
vdsm+engine logs

Description of problem:
Adding a new host fails with "ExecutionException", installation ends successfully and host is up.

from engines logs:
2014-07-13 16:12:41,159 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-8-thread-44) [2cbee80b] java.util.concurrent.ExecutionException: java.lang.
  2014-07-13 16:12:41,162 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-8-thread-44) [2cbee80b] Command PollVDSCommand(HostName = vdsc, HostId = 65
  2014-07-13 16:12:41,820 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-8-thread-44) [2cbee80b] org.ovirt.engine.core.vdsbroker.vdsbroker.VDSRecove
  2014-07-13 16:12:41,824 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-8-thread-44) [2cbee80b] Command PollVDSCommand(HostName = vdsc, HostId = 65


Version-Release number of selected component (if applicable):

ovirt-engine-3.5.0-0.0.master.20140629172257.git0b16ed7.el6.noarch
vdsm-4.16.0-3.git601f786.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.add host

Actual results:
operation fails on logs

Expected results:
if installation is successful operation shouldn't fail on logs.

Additional info:

Comment 1 Oved Ourfali 2014-07-14 10:51:43 UTC
During installation the host-deploy starts VDSM and the engine monitors it for 2 minutes, so it can take some time for the vdsmd service to become up.
In this period of time there might be errors in the log.
Closing as notabug.

Comment 2 Sven Kieske 2014-07-14 11:09:23 UTC
This bug is about those errors during vdsm monitoring.

What are the reasons for these errors?
If setup works correct, and it can start vdsm what errors are generated
just in the first 2 minutes after the first start and never thereafter again?

Is this a bug in the design or in the implementation of host-deploy?

I would assume the following:

a correct and working host-deploy flow should not generate any error messages
in any log.

So if vdsm needs that much time to boot, shouldn't the host-deploy
design be redesigned so vdsm notificates engine when it is up?

there should be a clear definition about the response time of vdsm
after startup, and when vdsm responds within this specified time
no errors should be logged.

Comment 3 Ori Gofen 2014-07-15 06:48:17 UTC
After further thought and discussion,I've reopened.
This error is misleading and will make it harder to support the system in case of a real failure.

Comment 4 Sven Kieske 2015-04-20 07:58:23 UTC
Why is this closed "wontfix" without even giving a reason?

Comment 5 Oved Ourfali 2015-04-20 10:24:37 UTC
It is in the process of closing old bugs that we don't plan to fix, as this requires efforts that we aren't planning to spend for the next versions, and the issue is minor.

If you think it is important you can reopen for consideration in the future.

Comment 6 Sven Kieske 2015-04-20 10:56:34 UTC
Well, yes, I think it is important.

At least it should be checked versus an actual version of ovirt, maybe it got
fixed by other means.

However I can't "reopen" the bug, as I have no permission to change the status of the bug.


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