Red Hat Bugzilla – Bug 750886
Drift: After compliance, a return to bad state is ignored
Last modified: 2012-02-07 14:26:38 EST
1) For a resource, create a definition and generate the initial snapshot
2) Edit a file being monitored (FileA) with a simple edit like "EDIT #1"
3) Wait for Snapshot 1 and validate the edit
4) Pin Snapshot 1 to the definition
5) The definition is now pinned and reset to snapshot 0.
6) Edit FileA with a simple but different edit, like "EDIT #2"
7) The definition is now out of compliance and generates Snapshot 1.
8) Validate snapshot 1
9) Fix FileA by reverting the last edit back to "EDIT #1"
10) The definition goes back into compliance. WAIT LONG ENOUGH such that
you are sure this is the case (meaning a detection cycle occurs).
11) Reinstate the original problem, edit FileA to "EDIT #2"
This does not generate snapshot 2. It should.
Note that any other edit does in fact generate snapshot 2, so the
isse is specific to drift detection still somehow comparing against
The problem here stemmed from not updating the current snapshot when the resource goes back into compliance. The current snapshot file was stale in that it did not reflect the current state which would be the same as the pinned snapshot. With those changes, going through the steps to reproduce does generate a new snapshot at step 11 where you reinstate the original problem.
master branch commit hash: 098139720bb55945fc241fee337c403b2ce70adc
release_jon3.x commit hash: 0d520a33a83e85fd2ef57ab77b11dbfdddc023a9
I want to stress that because all of the functionality around compliance is not fully implemented, the behavior introduced by this commit is likely to change to some degree. With this commit when a resource goes back into compliance, the agent reports an empty change set to the server. This may seem a bit unintuitive to users, but this is likely going to change any way. Instead when a resource goes back into compliance, the agent will make a separate call to the server indicating that the resource is back in compliance. Then we would not see the empty change set.
verified build #684
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE