Bug 1253230 - Confusing log level for "Policy reset" message when running setupNetworks
Confusing log level for "Policy reset" message when running setupNetworks
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: General (Show other bugs)
---
Unspecified Unspecified
unspecified Severity medium (vote)
: ovirt-3.6.1
: 3.6.1
Assigned To: Piotr Kliczewski
Pavol Brilla
:
: 1273407 1273408 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-13 05:21 EDT by Pavel Stehlik
Modified: 2016-02-18 06:16 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-18 06:16:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑3.6.z+
mgoldboi: planning_ack+
oourfali: devel_ack+
pstehlik: testing_ack+


Attachments (Terms of Use)
logs.tgz (30.75 KB, application/x-gzip)
2015-08-13 05:21 EDT, Pavel Stehlik
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 46101 ovirt-engine-3.6 NEW core: reduce log level for policy reset Never
oVirt gerrit 47521 master MERGED core: reduce log level for policy reset Never
oVirt gerrit 47523 ovirt-engine-3.6 MERGED core: reduce log level for policy reset Never
oVirt gerrit 47525 ovirt-engine-3.6.0 MERGED core: reduce log level for policy reset Never
oVirt gerrit 47553 ovirt-engine-3.6.0 ABANDONED Revert "core: reduce log level for policy reset" Never
oVirt gerrit 47651 ovirt-engine-3.6.0 MERGED Revert "core: reduce log level for policy reset" Never

  None (edit)
Description Pavel Stehlik 2015-08-13 05:21:03 EDT
Created attachment 1062416 [details]
logs.tgz

Description of problem:
 When adding host the ERROR message appeared: "VDSM <fqdn-of-my-host> command failed: Policy reset" 
In the vdsm.log nor supervdsm.log can't see any error.

engine.log:
2015-08-13 09:50:42,094 INFO  [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [1fcd3382] Connecting to <FQDN-of-my-host>/<IP-of-my-host>
2015-08-13 09:50:42,147 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-7-thread-3) [20127663] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VDSM <FQDN-of-my-host> command failed: Policy reset
2015-08-13 09:50:42,147 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-7-thread-3) [20127663] Command 'PollVDSCommand(HostName = <FQDN-of-my-host>, VdsIdVDSCommandParametersBase:{runAsync='true', hostId='b9ce9025-8b15-4b96-89eb-7c607e7361f6'})' execution failed: VDSGenericException: VDSNetworkException: Policy reset
2015-08-13 09:50:42,147 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-7-thread-3) [20127663] Error: VDSGenericException: VDSNetworkException: Policy reset


Version-Release number of selected component (if applicable):
rhevm-3.6.0-0.11.master.el6.noarch
vdsm-4.17.2-1.el7ev.noarch
(rhel: engine 6.7, host 7.2)

How reproducible:


Steps to Reproduce:
1. add host with using FQDN into engine through webadmin
2.
3.

Actual results:
Non-descriptive Error about Policy.

Expected results:


Additional info:
Comment 1 Piotr Kliczewski 2015-09-04 09:35:54 EDT
Policy reset it is standard behavior of the engine when we attempt to run setupNetworks. We make sure that connection to vdsm is health by sending heartbeat but when we run setupNetworks we know that were are about to have networking issues so we need to reset policy and stop expecting heartbeats. There is only one way in the engine to pass that information to higher layers by
throwing an exception.

What would be acceptable description for you?
Comment 2 Pavel Stehlik 2015-09-07 04:56:24 EDT
I don't understand why ERROR is mentioned in the log when it is expected behaviour. I'd rather see proper severity, thus if using kinda semaphore as communication - shouldn't scare user.
Comment 3 Piotr Kliczewski 2015-09-07 06:24:49 EDT
Ok, let's check severity for this specific message.
Comment 4 Red Hat Bugzilla Rules Engine 2015-10-19 06:56:52 EDT
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 5 Moti Asayag 2015-10-20 09:15:01 EDT
*** Bug 1273408 has been marked as a duplicate of this bug. ***
Comment 6 Moti Asayag 2015-10-21 01:01:44 EDT
*** Bug 1273407 has been marked as a duplicate of this bug. ***
Comment 7 Sandro Bonazzola 2015-10-21 02:39:58 EDT
How is it possible that this bug has all the referenced patches merged up to 3.6.0 branch and it's still missing all the required acks?
Comment 8 Sandro Bonazzola 2015-10-21 05:01:31 EDT
Please note that even if the fix has been merged in 3.6.0 branch, since this is not approved as blocker it won't cause a rebuild for 3.6.0 GA.
Please either approve this as blocker or postpone to 3.6.1.
Comment 9 Red Hat Bugzilla Rules Engine 2015-10-22 08:45:43 EDT
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.
Comment 10 Red Hat Bugzilla Rules Engine 2015-10-22 08:45:43 EDT
Fixed bug tickets must have target milestone set prior to fixing them. Please set the correct milestone and move the bugs back to the previous status after this is corrected.
Comment 12 Red Hat Bugzilla Rules Engine 2015-10-22 08:48:52 EDT
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 13 Red Hat Bugzilla Rules Engine 2015-10-22 08:48:52 EDT
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.
Comment 14 Yaniv Lavi 2015-10-29 08:29:14 EDT
In oVirt testing is done on single release by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.
Comment 16 Red Hat Bugzilla Rules Engine 2015-11-26 23:37:38 EST
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
Comment 17 Pavol Brilla 2016-01-21 09:58:46 EST
Verified on 3.6.2.6-0.1.el6

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