Bug 749871 - Drift alerts continue to fire after re-pinning
Drift alerts continue to fire after re-pinning
Status: CLOSED NOTABUG
Product: RHQ Project
Classification: Other
Component: drift (Show other bugs)
4.1
Unspecified Unspecified
high Severity medium (vote)
: ---
: ---
Assigned To: Jay Shaughnessy
Mike Foley
:
Depends On:
Blocks: 707225
  Show dependency treegraph
 
Reported: 2011-10-28 14:33 EDT by Mike Foley
Modified: 2011-11-02 10:48 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-02 10:48:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mike Foley 2011-10-28 14:33:54 EDT
Description of problem:  Drift alerts continue to fire after re-pinning.  




Steps to Reproduce:
1.  create a drift configuration
2.  create an alert that fires on drift detection
3.  add/change some files so that drift detection occurs ... and the drift alert fires
4.  pin the drift configuration to snapshot 1.  
5.  by definition  you are in full compliance
6.  drift alert continues to fire.  <<--bug
  
Actual results:
drift alerts continue to fire.

Expected results:
drift alerts do not continue to fire because after re-pinning, by defintion, you are in full compliance.

Additional info:
scenario #3 http://jbosson.etherpad.corp.redhat.com/9
Comment 1 Jay Shaughnessy 2011-11-02 09:22:32 EDT
I'm not sure about this.  Alerts only fire when snapshot reports come in
from the agent.  In that case you'd see more snapshots for the
definition (the "config" term is dead).  How you could generate alerts
without getting more snapshots is unclear.  I'll try it but this may be a
testing issue.
Comment 2 Jay Shaughnessy 2011-11-02 10:02:15 EDT
Well, actually, once pinned you can generate alerts without getting
more snapshots. But only when you are out of compliance.  In which
case the alert will fire on every detection cycle for the same drift which
is indicating the out of compliance situation.
Comment 3 Jay Shaughnessy 2011-11-02 10:42:22 EDT
I could not reproduce this issue. After pinning the alerting stopped, as
it should because, as it states in step 5 of the repro steps, the
system is in compliance.  I tried an agent restart just to make sure it
was not a strange sync issue but that did not cause any problem.

As long as the snapshot version after the pinning is "0" then there should
be no alerting. *IF* there was reported drift after the pinning, and the
snapshot version is 1 (or higher) the situation would be as described, as
a file would remain out of compliance.

Also, if the tester had *more than one* definition for the resource, and
did not restrict the alert definition to the one definition being tested
in this BZ, then alerts could have been fired due to drift reported for
the other definitions.

No changes being made, please re-test.
Comment 4 John Sanda 2011-11-02 10:45:16 EDT
I retested this and got the expected results. There is one thing to consider
that could have led to the reported results. Suppose your definition is pinned,
and then you generate some drift such that you have snapshots 0, 1, and 2. Then
you re-pin against snapshot 1. In this situation you would still generate drift
and alerts after re-pinning because what was snapshot 2 will still get detected
as drift again.
Comment 5 Mike Foley 2011-11-02 10:48:57 EDT
discussed with jsanda and retested.  the explanation of pinning against snapshot 1 (when there is shapshots 0, 1, and 2) is plausible.  cannot reproduce.

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