Bug 750886 - Drift: After compliance, a return to bad state is ignored
Summary: Drift: After compliance, a return to bad state is ignored
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: drift
Version: 4.2
Hardware: All
OS: All
medium
high
Target Milestone: ---
: ---
Assignee: John Sanda
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: 707225
TreeView+ depends on / blocked
 
Reported: 2011-11-02 17:14 UTC by Jay Shaughnessy
Modified: 2012-02-07 19:26 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-07 19:26:38 UTC
Embargoed:


Attachments (Terms of Use)

Description Jay Shaughnessy 2011-11-02 17:14:41 UTC
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 13:05:11 UTC
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 18:32:21 UTC
verified build #684

Comment 3 Mike Foley 2012-02-07 19:26:38 UTC
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.