Bug 750886 - Drift: After compliance, a return to bad state is ignored
Drift: After compliance, a return to bad state is ignored
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: drift (Show other bugs)
4.2
All All
medium Severity high (vote)
: ---
: ---
Assigned To: John Sanda
Mike Foley
:
Depends On:
Blocks: 707225
  Show dependency treegraph
 
Reported: 2011-11-02 13:14 EDT by Jay Shaughnessy
Modified: 2012-02-07 14:26 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-07 14:26:38 EST
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 Jay Shaughnessy 2011-11-02 13:14:41 EDT
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
something stale.
Comment 1 John Sanda 2011-11-03 09:05:11 EDT
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.
Comment 2 Mike Foley 2011-11-03 14:32:21 EDT
verified build #684
Comment 3 Mike Foley 2012-02-07 14:26:38 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

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