Bug 1025782 - rhq_agent_env.sh and RHQ Agent Launcher Script resource becomes invalid after agent update/re-install using a different file system path or RPM update is performed
rhq_agent_env.sh and RHQ Agent Launcher Script resource becomes invalid after...
Status: NEW
Product: JBoss Operations Network
Classification: JBoss
Component: Upgrade, Inventory, RPM (Show other bugs)
JON 3.2
x86_64 Linux
unspecified Severity low
: ---
: JON 3.4.0
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-01 10:52 EDT by Armine Hovsepyan
Modified: 2015-09-02 20:03 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Armine Hovsepyan 2013-11-01 10:52:25 EDT
Description of problem:
rhq_agent_env.sh is not being updated on gui after agentRPM upgrade

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

How reproducible:
always

Steps to Reproduce:
1. install jon 3.1.2 server on IP1
2. install jon 3.1.2 agent via RPM on IP2 and connect to server on IP1
3. upgrade server on IP1 to jon 3.2 er4
4. upgrade agent rpm on IP2 to 3.2 er4
5. navigate to agent(installed on ip2) resource in inventory gui (server ip1)

Actual results:
rhq_agent_env.sh resource is inactive and not updated -> http://d.pr/i/EG67

Expected results:
rhq_agent_env.sh resource updated and active -> http://d.pr/i/FJT2

Additional info:
rhq-agent_env.sh contains path to old agent, uninventory-inventory of agent fixes issue
Comment 5 Larry O'Leary 2014-01-07 17:02:31 EST
In this case, the rhq-agent-env.sh and RHQ Agent Launcher Script resources become invalid due to the agent's file system path changing. In other words, the files were originally located in "/opt/jboss/jboss-on/3.1.2.GA/agent/bin/" but once the upgrade is complete, they are located in "/opt/jboss/jboss-on/3.2.0.GA/agent/bin/". During discovery the new files are discovered in the new location. However, they are silently ignored/dropped because the newly assigned resource key for these two resources happen to match the already existing resources. In the end, they are merged with the existing resources but the existing plug-in configuration remains in place. When the availability check runs -- which is simply a [if file exists] check -- it fails due to the no invalid path. 

This same problem affects many other resource types managed by the JBoss ON system. In some cases, plug-in configuration of child servers and services need to auto-reconcile these types of differences. In this case, discovery of the updated path should trigger the update of the plug-in configuration. Keep in mind though that this isn't always the case. We should only perform this reconcilabition when we know it is safe or expected for the resource in question.

At bare minimum, when we have plug-in configuration that is static and depends on something variable and aren't sure if auto-reconciling makes sense, then the resource key should be augmented to result in duplicate resources with unique keys and possibly better configuration choices. This will allow the user to choose to get rid of the old one or fix the problem that caused the duplicate and get rid of the new one.

In this case, the choice seems simple; we update the pathname in the plug-in configuration because we know that this agent's path (RHQ_AGENT_HOME) is different then the script's path. Or perhaps the script's path should be relative to the resource?

If we want to take the safer way out -- with the potential to confuse the user -- we should discover a second rhq-agent-env.sh and RHQ Agent Launcher Script resource and add them both to inventory. The result being that there are two of each resource. One of the resources would be DOWN while the other would be UP and the user could UNINVENTORY the DOWN one if they chose (a manual merge/reconcile would be preferred though so they could keep resource history).

Until this issue is fixed, what this BUG means is that these resources will always be down unless the user removes them from inventory and waits for the results of a service discovery for the parent resource.
Comment 6 Jay Shaughnessy 2014-08-26 17:53:53 EDT
Moving to 3.3 ER03 for further evaluation, may get bumped later.
Comment 7 Stefan Negrea 2014-09-05 11:55:29 EDT
This issue exists even for newer RPMs (post 3.2 CP1) even if the upgrade process requires a complete removal of the old RPM and fresh install of the new RPM. Comment 5 explains correctly the problem.

A fix can be targed for the agent files since the upgrade process for RPMs is known and supported. MISSING state coupled with a discovery fix for these file based resources could be the solution.
Comment 9 Simeon Pinder 2014-09-29 04:12:33 EDT
Moving into ER05 as didn't make the ER04 cut.
Comment 10 Jay Shaughnessy 2014-10-09 14:54:42 EDT
Going forward this should strictly be an RPM issue because non-RPM installs keep the agent in the same place, in general.

I think the solution is to implement resource upgrade for the types in question.  If the current discovery finds a path different from the current path, perform the update.

I'll look into doing this.  Note that the built-in paths for the log sources on RHQ Agent are another potential issue like this one.
Comment 11 Jay Shaughnessy 2014-10-09 14:58:43 EDT
Changed my mind. I still think that's the way to go, but pushing due to low priority and various workarounds.

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