Bug 738036

Summary: Drift regression, changeset erroneously reports all files as new, again
Product: [Other] RHQ Project Reporter: Mike Foley <mfoley>
Component: driftAssignee: John Sanda <jsanda>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: medium    
Version: 4.1CC: jsanda
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-07 19:17:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
agent log
none
version 0 changeset
none
version 1 changeset
none
version 2 changeset
none
version 3 changeset none

Description Mike Foley 2011-09-13 17:25:09 UTC
Created attachment 522969 [details]
agent log

Description of problem:  Drift regression, changeset erroneously reports all files as new, again


Version-Release number of selected component (if applicable):
RHQ 4.1.1 09/13/2011 build

How reproducible:
100%

Steps to Reproduce:
1.   add drift configuration on a filesystem.  no includes, no excludes.  60 second interval.  enabled.
2.   initial version #0 drift changeset is reported (see attached image version0.png)
3.   add 1 file  (see attached image version1.png)
4.   edit 1 file (see attached image version2.png)
5.   version #3 changeset erroneously reports all files as new, again (see attached image version4.png)

Actual results:
version #3 changeset reports 12 new files, which is incorrect.

Expected results:
version #3 changeset should not even exist.

Additional info:
attached images.  attached agent log.  attached server log.

Comment 1 Mike Foley 2011-09-13 17:25:36 UTC
Created attachment 522970 [details]
version 0 changeset

Comment 2 Mike Foley 2011-09-13 17:25:58 UTC
Created attachment 522971 [details]
version 1 changeset

Comment 3 Mike Foley 2011-09-13 17:26:19 UTC
Created attachment 522972 [details]
version 2 changeset

Comment 4 Mike Foley 2011-09-13 17:26:41 UTC
Created attachment 522973 [details]
version 3 changeset

Comment 5 John Sanda 2011-09-13 19:04:53 UTC
This issue was actually identified by Jay yesterday. The regression was introduced as part of inventory sync work for bug 732102. When the agent runs a discovery scan and new resources are discovered, an inventory sync is triggered. In the agent code that syncs drift configurations with the server, I was treating existing configs as new ones and rescheduling them. This resulted in a new coverage change set being generated. You can see this in the agent.log file that is attached. On line 232 of the log file we have,

2011-09-13 11:54:16,786 INFO  [WorkerThread#0[10.0.1.189:44604]] (rhq.core.pc.drift.DriftManager)- Received request to schedule drift detection immediately for [resourceId: 10001, driftConfigurationId: 10001, driftConfigurationName: File System]

Then on line 259 we have,

2011-09-13 12:03:08,620 INFO  [InventoryManager.discovery-1] (rhq.core.pc.inventory.AutoDiscoveryExecutor)- Executing server discovery scan...


And finally lines 273 - 275,

2011-09-13 12:03:16,277 INFO  [InventoryManager.discovery-1] (rhq.core.pc.inventory.InventoryManager)- Syncing local inventory with Server inventory...
2011-09-13 12:03:16,395 INFO  [InventoryManager.discovery-1] (rhq.core.pc.drift.DriftManager)- Received request to unschedule drift detection for [resourceId:10001, driftConfigurationId: 10001, driftConfigurationName: File System].
2011-09-13 12:03:16,396 INFO  [InventoryManager.discovery-1] (rhq.core.pc.drift.DriftManager)- Scheduling drift detection for DriftDetectionSchedule[resourceId: 10001, driftConfigurationId: 10001, driftConfigurationName: File System]


When drift detection is unscheduled, the snapshot file on disk is removed. Then when the scheduled is created again, the agent will generate a new snapshot and send a coverage change set report to the server which is of course a duplicate.

A check has been put in place so that we only add new schedules and do not delete existing ones.

commit hash: 0b8f83bf0d49e01f3d554a4fcd72258b0f95e08d

Comment 6 Mike Foley 2011-09-14 14:18:37 UTC
verified RHQ 4.1 sprint 5 Test Day.

Comment 7 Mike Foley 2012-02-07 19:17:50 UTC
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE