Red Hat Bugzilla – Bug 592038
RFE:Support updating resource keys (in particular apache)
Last modified: 2013-09-02 03:16:19 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
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
2 apache resources pointing to the same apache installation.
1 apache instance in the inventory correctly upgraded to use the new plugin.
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
we're gonna back out the apache change and re-introduce in the next release. see 612189
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
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.
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.
Reducing severity as this is no longer targeted for the JON2.4 release
*** Bug 536297 has been marked as a duplicate of this bug. ***
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.
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.