Bug 1025782

Summary:	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
Product:	[JBoss] JBoss Operations Network	Reporter:	Armine Hovsepyan <ahovsepy>
Component:	Upgrade, Inventory, RPM	Assignee:	RHQ Project Maintainer <rhq-maint>
Status:	CLOSED EOL	QA Contact:	Mike Foley <mfoley>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	JON 3.2	CC:	fbrychta, jshaughn, loleary, mfoley, myarboro, spinder
Target Milestone:	---
Target Release:	JON 3.4.0
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-20 14:55:00 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:

Description Armine Hovsepyan 2013-11-01 14:52:25 UTC

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 22:02:31 UTC

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 21:53:53 UTC

Moving to 3.3 ER03 for further evaluation, may get bumped later.

Comment 7 Stefan Negrea 2014-09-05 15:55:29 UTC

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 08:12:33 UTC

Moving into ER05 as didn't make the ER04 cut.

Comment 10 Jay Shaughnessy 2014-10-09 18:54:42 UTC

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 18:58:43 UTC

Changed my mind. I still think that's the way to go, but pushing due to low priority and various workarounds.

Comment 13 Filip Brychta 2019-05-20 14:55:00 UTC

JBoss ON is coming to the end of its product life cycle. For more information regarding this transition, see https://access.redhat.com/articles/3827121.
This bug report/request is being closed. If you feel this issue should not be closed or requires further review, please create a new bug report against the latest supported JBoss ON 3.3 version.