Bug 1136998 - Support resource upgrade callbacks in plugins
Summary: Support resource upgrade callbacks in plugins
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Agent
Version: JON 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER04
: JON 3.3.0
Assignee: Lukas Krejci
QA Contact: Filip Brychta
URL:
Whiteboard:
Depends On: 1136996
Blocks: JON3-10, PRODMGT-544 1135034
TreeView+ depends on / blocked
 
Reported: 2014-09-03 19:34 UTC by Lukas Krejci
Modified: 2014-12-11 14:01 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1136996
Environment:
Last Closed: 2014-12-11 14:01:46 UTC
Type: Bug


Attachments (Terms of Use)

Description Lukas Krejci 2014-09-03 19:34:32 UTC
+++ 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).

Comment 1 Lukas Krejci 2014-09-05 12:12:23 UTC
Proposed fix: https://github.com/rhq-project/rhq/pull/121

Comment 2 Thomas Segismont 2014-09-10 14:59:14 UTC
Merged in release/jon3.3.x

commit 4cedda3a24228c93f0621e3c0aa8dd6043043e32
Author: Thomas Segismont <tsegismo@redhat.com>
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"

Comment 3 Simeon Pinder 2014-09-17 02:49:25 UTC
Moving to ON_QA as available for test with the following brew build:
https://brewweb.devel.redhat.com//buildinfo?buildID=385149

Comment 7 Filip Brychta 2014-09-23 10:36:51 UTC
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

Comment 8 Lukas Krejci 2014-09-23 11:05:41 UTC
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.

Comment 9 Lukas Krejci 2014-09-23 21:38:45 UTC
master:
commit 1759352ee3ca4f184872aa55d9530d54a12c42df
Author: Lukas Krejci <lkrejci@redhat.com>
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@redhat.com>
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)

Comment 10 Simeon Pinder 2014-10-01 21:33:36 UTC
Moving to ON_QA as available for test with build:
https://brewweb.devel.redhat.com/buildinfo?buildID=388959

Comment 11 Filip Brychta 2014-10-07 10:28:13 UTC
Verified on
Version :	
3.3.0.ER04
Build Number :	
99d2107:d7c537e


Note You need to log in before you can comment on or make changes to this bug.