Bug 871873

Summary:	Availability check change is not automatically picked up
Product:	[Other] RHQ Project	Reporter:	Larry O'Leary <loleary>
Component:	Agent	Assignee:	Thomas Segismont <tsegismo>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Mike Foley <mfoley>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.4	CC:	bkramer, hrupp, jshaughn, loleary, tsegismo
Target Milestone:	---
Target Release:	RHQ 4.6
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	869716	Environment:
Last Closed:	2013-09-03 14:42:19 UTC	Type:	Bug
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:	869716

Description Larry O'Leary 2012-10-31 15:31:41 UTC

+++ 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 17:00:34 UTC

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 14:00:55 UTC

Jay,

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 14:05:13 UTC

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
30s/30s
42s/1m
67s/1m30s

Comment 4 Thomas Segismont 2012-11-29 21:26:22 UTC

Merged into master 257e056

Remote branch bug/871873 deleted

Comment 5 Thomas Segismont 2012-11-29 21:31:28 UTC

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 14:42:19 UTC

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.