+++ This bug was initially created as a clone of Bug #1136996 +++ Description of problem: The DiscoveryCallback mechanism has been introduced to allow of influencing discovery results of resource types from other plugins. The picture is incomplete without also having the ability to similarly affect the resource upgrade which, too, can result in resource's plugin config or name or res key changes. Having the ability to intercept both the discovery and resource upgrade gives the implementors complete control over the discovery-related details of the resource (plugin config, name, description, version, etc.). As an example: We implement a discovery callback that changes a name of an EAP server found to be the RHQ server to end with the "RHQ Server" string. If such server was in inventory prior to having the plugin with the callback installed in RHQ, the name cannot be updated (without resource upgrade callback).
Proposed fix: https://github.com/rhq-project/rhq/pull/121
Merged in release/jon3.3.x commit 4cedda3a24228c93f0621e3c0aa8dd6043043e32 Author: Thomas Segismont <tsegismo> Date: Wed Sep 10 16:57:51 2014 +0200 BZs 1136996 1135034 1135107 - Check if patching is supported before trying to perform it on EAP based resource From patch file created with "git diff a3a59ff 5c39e3a"
Moving to ON_QA as available for test with the following brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=385149
Used following scenario: 1- install JON3.2.0.GA with eap plugin pack 2- register remote agent which is monitoring eap6 3- import all resources 4- upgrade the JON to JON.3.3.0.ER03 - stop old jon - upgrade jon to er03 - copy new plugins to jon_home/plugins - update plugins on all agents 5- import new JON server resource Result: - new JON server resource has the Supports Patching property set to Yes - this is NOT correct - old JON server resource has the Supports Patching property set to No - this is correct - eap6.3.0 resource has the Supports Patching property set to Yes - this is correct
This works on fresh installs so this seems to be some kind of strange interaction between the "old" and "new" server in the inventory. I don't have an explanation yet for why this is happening.
master: commit 1759352ee3ca4f184872aa55d9530d54a12c42df Author: Lukas Krejci <lkrejci> Date: Tue Sep 23 23:19:09 2014 +0200 [BZ 1136998] Fix the logic in the upgrade delegate. It now better distinguishes between configuration values coming from a previous upgrade report in the chain versus the values coming from the existing resource. Being aware of the distinction is needed for a correct decision on what value should the "supportsPatching" attribute set to. release/jon3.3.x: commit 20f245495c82a968606192310beedd68972ce9b5 Author: Lukas Krejci <lkrejci> Date: Tue Sep 23 23:19:09 2014 +0200 [BZ 1136998] Fix the logic in the upgrade delegate. It now better distinguishes between configuration values coming from a previous upgrade report in the chain versus the values coming from the existing resource. Being aware of the distinction is needed for a correct decision on what value should the "supportsPatching" attribute set to. (cherry picked from commit 1759352ee3ca4f184872aa55d9530d54a12c42df)
Moving to ON_QA as available for test with build: https://brewweb.devel.redhat.com/buildinfo?buildID=388959
Verified on Version : 3.3.0.ER04 Build Number : 99d2107:d7c537e