Bug 592038

Summary: RFE:Support updating resource keys (in particular apache)
Product: [Other] RHQ Project Reporter: Lukas Krejci <lkrejci>
Component: PluginsAssignee: Lukas Krejci <lkrejci>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: high    
Version: 3.0.0CC: ccrouch, skondkar
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-02 03:16:19 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 536328, 577313, 625146    

Description Lukas Krejci 2010-05-13 14:07:32 EDT
Description of problem:

The resource key generation algorithm changed for Apache during the recent updates to it. But this causes problems when upgrading RHQ from previous versions because the old resource (with the old style resource key) remains in the inventory. After the upgrade, when the agent is doing its regular discovery, the apache is found as it should, but a different resource key is assigned to it. This causes the server to think that it is a new resource placing it in the autodiscovery queue.

Further, the configuration data of the pre-upgrade resource are not updated with the default values of the new configuration properties introduced by the new plugin functionality making it appear down and with not much help left for the user to fill in the advanced properties like the name of the Augeas lens to use.

Version-Release number of selected component (if applicable):
1.3.1 upgraded to latest

How reproducible:
always

Steps to Reproduce:
1. Have RHQ 1.3.1 server inventory an apache instance.
2. Upgrade the RHQ server to the latest RHQ 3.0.0 snapshot.
3. Notice that the Apache server appears again in the autodiscovery queue
  
Actual results:
2 apache resources pointing to the same apache installation.

Expected results:
1 apache instance in the inventory correctly upgraded to use the new plugin.

Additional info:
Comment 1 Charles Crouch 2010-07-06 19:47:11 EDT
Mazz, is looking at this currently. If we don't fix the upgrade process for changed keys, we'll rollback the original change to the apache resource key
Comment 2 John Mazzitelli 2010-07-09 10:00:11 EDT
we're gonna back out the apache change and re-introduce in the next release. see 612189
Comment 3 Charles Crouch 2010-07-12 11:26:23 EDT
Comment from Mazz:
---

The new "resource upgrade" code performs all its work in the 
InventoryManager.initialize method, which is nice because its located in 
one spot (easy for maintenance), and doesn't affect the rest of the PC 
runtime (so it doesn't affect performance other than startup performance).

However, I recommend we hold off on this for 2.4 and put it in the next 
release. This is because we don't know the ramifications of what the 
agent behavior will be IF the server is down or an error otherwise 
occurs during the ugprade.

Remember one of our "golden rules" is that any registered agent should 
always be allowed to start and run, even if the server is down. If an 
agent is already registered, has its plugins and has persisted inventory 
(inventory.dat), even if the server is down (or the network is out), the 
agent will be able to start and can monitor its resources. When the 
server is back available, the agent can send its spooled messages.

In this resource upgrade case, if the server is down, it will fail 
during inventory manager initialize - will that cause the agent to abort 
its startup - will it cause the startup to encounter other errors and 
cause the agent to fail to fully prepare itself?

If the agent CAN still continue, is the inventory now corrupted because 
it no longer has updated resource keys (i.e. it has the old keys still). 
Will that cause problems when the agent starts to send messages up to 
the server?

So my big question is - what happens to the agent when the agent starts 
and the server is not available. We need to answer that satisfactorily 
before we put the resource upgrade code in master.
Comment 4 Lukas Krejci 2010-07-13 11:45:03 EDT
I updated the plugin to use the old-style resource key format for now (bug 612189) and reopened the original bug 536328 the required the resource key change.
Comment 5 Charles Crouch 2010-07-20 10:52:39 EDT
Reducing severity as this is no longer targeted for the JON2.4 release
Comment 6 Lukas Krejci 2010-11-16 03:38:22 EST
*** Bug 536297 has been marked as a duplicate of this bug. ***
Comment 7 Sunil Kondkar 2011-07-12 08:17:07 EDT
Verified on build#188 (Version: 4.1.0-SNAPSHOT Build Number: c45b0da)

Installed jon240 build and Upgraded to latest master build#188. The autodiscovery queue does not display Apache server appearing again.

The Apache server is up and the resource key is changed from '/etc/httpd' to '/etc/httpd||/etc/httpd/conf/httpd.conf'. The vhost resource key is changed from 'monitoring-test:8081' to 'monitoring-test:8081|127.0.0.1:8081'.

Marking as verified.
Comment 8 Heiko W. Rupp 2013-09-02 03:16:19 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.