Bug 737044

Summary: Investigate deferred link processing in the case of "agent unknown"
Product: Red Hat Enterprise MRG Reporter: Trevor McKay <tmckay>
Component: cuminAssignee: grid-maint-list <grid-maint-list>
Status: CLOSED WONTFIX QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: low Docs Contact:
Priority: low    
Version: DevelopmentCC: matt, sgraf
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: 2016-05-26 20:14:37 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:

Description Trevor McKay 2011-09-09 13:02:43 UTC 
Description of problem:

This is a tracker BZ.  On a very slow network (from home) a case was seen in which a jobserver object referenced a scheduler object, but the agent associated with the scheduler had been deleted by the time the jobserver update was processed (because of a timeout?).  Deferred link processing for the reference to the scheduler object was skipped, because the check for the agent failed.  This happened cyclically.

As a consequence, no submissions were ever displayed.  Even if the scheduler object was cyclically deleted, having submissions come and go on the screen would at least be a visual cue of a slow network (better than just blank forever).

Since the objId field contains the name of the agent in the reference, perhaps we can extend deferred link processing to include the unknown agent case, with some expiration date on deferred links spawned by unknown agents.  If we did this, when the scheduler object eventually was recreated submissions would have appeared (until the next timeout and delete).


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 2 Anne-Louise Tangring 2016-05-26 20:14:37 UTC 
MRG-Grid is in maintenance and only customer escalations will be considered. This issue can be reopened if a customer escalation associated with it occurs.