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
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.
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.
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.
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.
discussed with jsanda and retested. the explanation of pinning against snapshot 1 (when there is shapshots 0, 1, and 2) is plausible. cannot reproduce.