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:
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 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.
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.