Bug 871873

Summary: Availability check change is not automatically picked up
Product: [Other] RHQ Project Reporter: Larry O'Leary <loleary>
Component: AgentAssignee: Thomas Segismont <tsegismo>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.4CC: bkramer, hrupp, jshaughn, loleary, tsegismo
Target Milestone: ---   
Target Release: RHQ 4.6   
Hardware: All   
OS: All   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 869716 Environment:
Last Closed: 2013-09-03 10:42:19 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 869716    

Description Larry O'Leary 2012-10-31 11:31:41 EDT
+++ This bug was initially created as a clone of JBoss ON Bug #869716 +++

Description of problem:
When Availability check is changed, for instance from enabled to disabled, this change is not picked up by the agent and availability is still checked and server status changed depending on it's real state. 

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

How reproducible:
Every time.

Steps to Reproduce:
1. Import JBoss instance;
2. Navigate to Monitor -> Schedule (for that server instance) and disable Availability check;
3. After some time (at least 2 minutes if Availability check was initially set to 1 minute), stop the JBoss instance;
4. Execute "avail --force" on the JON Agent command line;
5. Check the status of the JBoss server;
Actual results:
The status of the JBoss instance changes to DOWN in JON UI. 

Expected results:
JBoss stays UP because it picks up the status of its parent resource (platform) as explained in [1]. 

Additional info:
The change in Availability check will be propagated after the agent is restarted with "--purgedata" option.

[1] https://access.redhat.com/knowledge/docs/en-US/JBoss_Operations_Network/3.1/html-single/Admin_Setting_up_Monitoring_Alerts_and_Operations/index.html#avail-backfill
Comment 1 Jay Shaughnessy 2012-11-28 12:00:34 EST
I can see that  MeasurementManager.scheduleCollection() is doing the correct thing, but  that is when we are setting the entire set of collection schedules.   When updating in MeasurementManager.updateCollection() it does look like  the avail metric is ignored.  If it is in the set it should be updated.
Comment 2 Thomas Segismont 2012-11-29 09:00:55 EST

The availability schedule is not in the set. So I have made a fix inspired by what is done in MeasurementManager.scheduleCollection().

Could you please review the modifications done in the specific branch ?
bug/871873 f6699a7
Comment 3 Thomas Segismont 2012-11-29 09:05:13 EST
Caveat that because of the internal behavior of availability checking, the "real" schedule will always be a multiple of 30s (rate of the availability check executor thread).

UI schedule/Actual schedule
Comment 4 Thomas Segismont 2012-11-29 16:26:22 EST
Merged into master 257e056

Remote branch bug/871873 deleted
Comment 5 Thomas Segismont 2012-11-29 16:31:28 EST
Please ignore comment 3: the "real" interval can indeed be longer than the interval saved in UI, as availability scheduled is respected on best effort.

But the interval is not necessarily a multiple of 30s
Comment 6 Heiko W. Rupp 2013-09-03 10:42:19 EDT
Bulk closing of issues in old RHQ releases that are in production for a while now.

Please open a new issue when running into an issue.