This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 712429

Summary: Plug-in configuration upgrade should contain resource name of conflicting resources in upgrade error/failure messages
Product: [Other] RHQ Project Reporter: Larry O'Leary <loleary>
Component: AgentAssignee: Lukas Krejci <lkrejci>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: high    
Version: 4.1CC: hrupp, lkrejci
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-01 15:18:59 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 678340    

Description Larry O'Leary 2011-06-10 11:10:43 EDT
When performing an upgrade of Apache resource plug-in configuration and ambiguous resource keys are detected, the current message simply indicates that the vhost resource key is ambiguous and asks the user to manually correct the issue. For usability the message must include which resource (by name and key) is ambiguous with this resource. This will allow the user to easily resolve the ambiguity without having to open each resource and manually reviewing to find the problem resource.
Comment 1 Lukas Krejci 2011-06-10 11:21:42 EDT
This is a generic issue of the plugin container, not directly tied to apache plugin because the conflict resolution is done in plugin container, not the plugins themselves - they just report what the resource keys should look like.
Comment 2 Charles Crouch 2011-06-15 11:30:45 EDT
Lukas
So does that mean we can or cannot fix this bug?
Comment 3 Lukas Krejci 2011-06-16 03:29:20 EDT
We can fix this, I just modified the bug title to not specifically mention apache because this needs (and can be) fixed generically for all plugins implementing resource upgrade.
Comment 4 Lukas Krejci 2011-06-16 13:35:09 EDT
commit ab97d23a233552d206f198f71bcdd711618a7bb0
Author: Lukas Krejci <lkrejci@redhat.com>
Date:   Thu Jun 16 19:26:15 2011 +0200

    BZ 712429 - giving out more useful error message in case of resource key conflict during the resource upgrade.
    The error message now contains the details of the resources given resource conflicts with so that the user can easily locate them.

-----------

An example of the error message given out:

java.lang.IllegalStateException: Upgrading the resource [Resource[id=10006, type=Apache Virtual Host, key=localhost.localdomain:0, name=Virtual Host localhost.localdomain:0, parent=localhost.localdomain Apache 2.2.17 (/home/metlos/Progs/apache-2.2.17/build/)]] using these updates [ResourceUpgradeRequest[resourceId = '10006', newResourceKey = 'injected-failure', newName = 'null', newDescription = 'null', upgradeErrorMessage = 'null', upgradeErrorStackTrace = 'null']] would render the inventory invalid because of the following reasons: After the upgrade, the following resources would have the same resource key which is illegal. This is an issue of either the old or the new version of the plugin 'Apache'. Please consult the documentation of the plugin to see what are the recommended steps to resolve this situation:
Resource[id=10005, type=Apache Virtual Host, key=127.0.0.1:11678, name=Virtual Host 127.0.0.1:11678, parent=localhost.localdomain Apache 2.2.17 (/home/metlos/Progs/apache-2.2.17/build/)],
Resource[id=10007, type=Apache Virtual Host, key=127.0.0.1:11676, name=Virtual Host 127.0.0.1:11676, parent=localhost.localdomain Apache 2.2.17 (/home/metlos/Progs/apache-2.2.17/build/)]
	at org.rhq.core.pc.upgrade.ResourceUpgradeDelegate.sendRequests(ResourceUpgradeDelegate.java:176)
	at org.rhq.core.pc.inventory.InventoryManager.activateAndUpgradeResources(InventoryManager.java:2714)
	at org.rhq.core.pc.inventory.InventoryManager.initialize(InventoryManager.java:228)
	at org.rhq.core.pc.PluginContainer.startContainerService(PluginContainer.java:425)
	at org.rhq.core.pc.PluginContainer.initialize(PluginContainer.java:279)
	at org.rhq.enterprise.agent.AgentMain.startPluginContainer(AgentMain.java:1867)
	at org.rhq.enterprise.agent.AgentMain.start(AgentMain.java:648)
	at org.rhq.enterprise.agent.AgentMain.main(AgentMain.java:418)
Comment 5 Mike Foley 2011-10-03 15:56:32 EDT
verified 10/3/2011 as follows:

1) wrote custom plugin
2) uploaded plugin
3) scan for updates, plugins update
4) discovered and inventoried resource
5) made configuration change 
6) upgraded plugin (version #, and some text)
7) uploaded updated plugin
8) scan for updates, plugins update
9) reviewed agent log for errors ... none
10) reviewed server log for errors ... none
11) reviewed UI to make sure it showed the configuration history
Comment 6 Larry O'Leary 2011-10-03 19:26:16 EDT
Not sure test steps cover this. This issue pertains to error messages that appear during the upgrade. The goal would be to ensure that reviewing the result in the UI, one can easily tell which resources the upgrade error pertained to.
Comment 7 Mike Foley 2011-10-04 10:16:44 EDT
code review of change 

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=ab97d23a233552d206f198f71bcdd711618a7bb0

String errorString = "Upgrading the resource [" + resource + "] using these updates ["
+                                + request + "] would render the inventory invalid because of the following reasons: "
+                                + upgradeErrors;

satisifies the verification
Comment 8 Lukas Krejci 2011-10-05 06:53:38 EDT
The code snippet above only differs in whitespace from the previous version, so I wouldn't call this verified.

The "meat" of the fix are the changes to the checkUpgradeValid() method, which produces the "upgradeErrors" in the code snippet above.

To verify this at runtime rather than just code inspection (choose whichever you see fit), you'd have to create a plugin which would have the following characteristics:

1) make sure your "original" version of the plugin discovers at least 2 resources of the same resource type under a single parent (i.e. 2 resources under a platform).

2) In the new version of the plugin, the discovery component of the resource type implements ResourceUpgradeFacet.

3) The upgrade() method on the discovery component needs to assign the same resource key to at least 2 pre-existing sibling resources (i.e. resources having the same parent resource). This creates the conflict.

4) When the agent updates the plugins, it should run the resource upgrade upon the start of the plugin container and should report the conflicts as resource errors on the conflicting resources. These should appear as the yellow warning triangles next to the availability icons on the resource details page and should contain the error message from which it would be clear what happened and what other resources are involved. Also the conflicting resources should be DOWN until the conflict clears.
Comment 9 Heiko W. Rupp 2013-09-01 15:18:59 EDT
Bulk closing of BZs that have no target version set, but which are ON_QA for more than a year and thus are in production for a long time.