Bug 884598 - Alert definitions are missing after JBoss is imported in JON
Alert definitions are missing after JBoss is imported in JON
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
Unspecified Unspecified
unspecified Severity medium (vote)
: ---
: RHQ 4.13
Assigned To: RHQ Project Maintainer
Mike Foley
Depends On:
Blocks: 884593
  Show dependency treegraph
Reported: 2012-12-06 06:15 EST by bkramer
Modified: 2014-09-03 15:28 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 884593
: 884593 (view as bug list)
Last Closed: 2014-09-03 15:28:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 68975 None None None Never

  None (edit)
Description bkramer 2012-12-06 06:15:57 EST
Description of problem:
It can happen that the JBoss instance is imported in the JON (using CLI) but it does not have Alert definitions specified when checking JON UI -> JBoss instance -> Alerts -> Definitions.

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

How reproducible:

Steps to Reproduce:

1. Start JON Server;
2. From JON UI navigate to Administration -> Alert Definition Templates -> Servers -> press Edit for JBossAS5 plugin -> add Alert templates;
3. Start JON Agent;
4. Start JBoss instance;
5. Let JON Agent discover JBoss instance (so it's visible in the Discovery Queue);
6. Shut down JON Agent;
7. Execute addJBoss.js script [1] from the JON CLI to inventory all JBoss instances that are in the discovery queue;
8. Confirm that JON UI has got in its inventory JBoss instance with availability UNKNOWN (as it's Agent is DOWN); 
9. From JON UI navigate to JBoss instance that should have alerts definitions defioned -> Alerts -> Definitions and confirm that they are not there.
10. Start JON Agent with --cleanconfig option;
11. Once the Agent is up and running, check the availability of the JBoss instance and confirm that it is GREEN.
12. From JON UI navigate to JBoss instance -> Alerts -> Definitions and confirm that this page is still empty.
Actual results:
Alert definitions page for imported JBoss instance is empty.

Expected results:
Alert Definitions page for imported JBoss instance contains alert definitions defined by the Alert definitions Template for JBossAS5.

Additional info:
If JON agent is re-started without --cleanconfig option, JBoss instance that was discovered and imported would become GREEN, but also it would have alert definitions added.

[1] https://access.redhat.com/knowledge/solutions/68975
Comment 1 Jay Shaughnessy 2013-09-11 17:07:57 EDT
This sounds like it may be a duplicate of Bug 969535.  I recommend testing this again with RHQ 4.8 or later.

If the test still fails please let me know.
Comment 2 bkramer 2013-09-13 05:23:15 EDT
(In reply to Jay Shaughnessy from comment #1)
> This sounds like it may be a duplicate of Bug 969535.  I recommend testing
> this again with RHQ 4.8 or later.
> If the test still fails please let me know.

I run the test using RHQ 4.9.0 and the same issue still exists - alert definition from the alert template is not added to the JBoss resource when the agent is restarted with --cleanconfig. If --cleanconfig is not used (just regular restart) then alert definition is added.
Comment 3 Jay Shaughnessy 2014-02-07 16:38:05 EST
Starting the agent --cleanconfig implicitly performs --purgedata, which deletes the agent's data directory.  By doing so the agent now has to get its inventory from the server.  That means that the resources are all considered previously UNKNOWN by the agent.  When bringing up the agent normally the resources would already be known to the agent, and be in the NEW state.  In the latter case we can see that the the resources have moved from NEW to COMMITTED when syncing with the server are startup.  As such we perform newly-committed resource actions, including alert template application.

For UNKNOWN resources we don't know the previous state and basically assume that a COMMITTED resource was previously committed and should not have the newly-committed actions applied.

This is a fair assumption as this will be the case in any scenario other the the current scenario, where not only was the agent down at import time but was also brought up --cleanconfig (or --purgedata).

The problem with changing this behavior is that if we apply the templates we could be undoing work performed by the users, who may have altered the previously applied templates and now would get them again just due to an agent restart.

The workaround here would just be to uninventory the problematic resource(s) and re-import them with the agent running, or with the agent later brought up normally.

Unless there is some common use-case for the scenario causing this problem I think this should be closed as won't fix, and the workaround used as necessary.
Comment 4 Heiko W. Rupp 2014-05-08 10:42:47 EDT
Bump the target version now that 4.11 is out.
Comment 5 Jay Shaughnessy 2014-07-07 13:44:08 EDT
I still think this should be closed/wontfix but for now bumping to 4.13 for further triage.
Comment 6 Jay Shaughnessy 2014-09-03 15:28:56 EDT
I'm closing this as Not A Bug.  It's a deep corner case, the behavior is as expected, and it has reasonable workarounds:
- uninventory and re-import
- manually update the template and have it re-applied to the existing inventory.

Note You need to log in before you can comment on or make changes to this bug.