Bug 1136998

Summary:	Support resource upgrade callbacks in plugins
Product:	[JBoss] JBoss Operations Network	Reporter:	Lukas Krejci <lkrejci>
Component:	Agent	Assignee:	Lukas Krejci <lkrejci>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Filip Brychta <fbrychta>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	JON 3.3.0	CC:	fbrychta, hrupp, mfoley, tsegismo
Target Milestone:	ER04
Target Release:	JON 3.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1136996	Environment:
Last Closed:	2014-12-11 14:01:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1136996
Bug Blocks:	1069547, 1135034

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>
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>
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)

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