Bug 734194

Summary: Failed to load change report viewing drift history
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: urgent    
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: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 707225    
Attachments:
Description Flags
Failed to load change report error
none
client-side error
none
server-side log (see the end of this file) none

Description Mike Foley 2011-08-29 17:18:05 UTC
Created attachment 520438 [details]
Failed to load change report error

Description of problem:  Failed to load change report viewing drift history



Steps to Reproduce:
1. Drift History
2. right-click context menu, details 
 
  
Actual results:
see attached

Expected results:


Additional info:
see attached.

Comment 1 Mike Foley 2011-08-29 17:19:25 UTC
Created attachment 520439 [details]
client-side error

Comment 2 Mike Foley 2011-08-29 17:20:49 UTC
Created attachment 520441 [details]
server-side log (see the end of this file)

Comment 3 Mike Foley 2011-08-29 19:25:20 UTC
additional info:
file type = .txt
drift type = template on jboss resource

Comment 4 John Sanda 2011-08-30 01:05:30 UTC
I have managed to produce the same server side stack trace that Mike reported. I see the "Failed to load change report" error message at the top of the screen as well. I do not yet have enough information about the initial finding to know if I have reproduced the issue or something different. Here are the steps I took to generate the same exception in the server log posted in comment 2:

1) For any resource make a change that will generate drift (neither the resource type nor the details of the drift configuration rules matter)

2)After the agent has sent the drift report to the server and before it sends the content, remove the content. This can be done by deleting the file or by changing the file contents so that it has a different SHA-256 hash. I did the latter. I should also note that I was able to get the timing of this just right by setting break points in the agent.


When the agent detects changes, it sends a drift report to the server. The server subsequently reviews the drift report looking for content that is not already in the database. 

Note that this is done asynchronously in a request different from the one sent by the agent that contained the drift report.

If the server finds that the drift report referencing content that is not already in the database, it sends a request to the agent asking for that content. By the time the agent was processing this request, I had already changed the original content such that it no longer existed.

The logic that I added in the drift details page for viewing files and diffs fails to take into account that content may not be available. In this case it is unavailable indefinitely. In other situations, maybe in scenarios involving heavier loads, the content still exists but just has not made its way to the server yet because requests are taking a long time to process.

The drift details page needs to be more robust about handling missing content. If the file to which the drift refers is text and if content is not yet available, then we need to indicate both that we supporting viewing that file and also that the content is not yet available. If content is unavailable indefinitely, then we need to indicate that as well.

Comment 5 John Sanda 2011-08-31 01:16:07 UTC
I have updated the drift details page to check for whether or not file content is already in the database. If no content is in the database for a file the corresponding 'view file' link will instead display a label saying content is not yet available. If content is not available for either the current or previous version of the file, then the link for viewing a diff will not be displayed.

commit hash: 4b12e68d2d7648ed08921f482bb02e3525a3cf81

Comment 6 Mike Foley 2011-08-31 18:15:33 UTC
possible regression with drift details page ... which i bz'd in https://bugzilla.redhat.com/show_bug.cgi?id=734879

Comment 7 Mike Foley 2011-08-31 18:25:06 UTC
another possible regression with drift details ... https://bugzilla.redhat.com/show_bug.cgi?id=734881

unable to verify this BZ.

Comment 8 Mike Foley 2011-10-05 20:38:58 UTC
verified build # 475 ... basic use-case, and with "scenario #7" network outage use-case.

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

Comment 10 Mike Foley 2012-02-07 19:30:37 UTC
marking VERIFIED BZs to CLOSED/CURRENTRELEASE