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.

Lukas
So does that mean we can or cannot fix this bug?

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.

commit ab97d23a233552d206f198f71bcdd711618a7bb0
Author: Lukas Krejci <lkrejci>
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)

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

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.

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

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.

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.