Related to https://bugzilla.redhat.com/show_bug.cgi?id=720674 We need to make sure no other plugins had accidental resource key changes.
Start a fresh JON 2.4.1 and take stuff into inventory. Record the resource keys from the database. Do the same with JON3 and check for differences
fix blocks/depends bz's
Created attachment 527254 [details] discovery component diffs
the attached diff between RHQ 3.0.1 and current master was created by running: $ git diff --no-color release-3.0.1..master `find -name '*DiscoveryComponent.java'` | gzip > discovery-components.diff.gz by inspecting the diff I found the following: apache plugin - ApacheServerDiscoveryComponent - with ResourceUpgradeFacet - ApacheVirtualHostServiceDiscoveryComponent - with ResourceUpgradeFacet jboss-as-5 plugin - AbstractManagedDeploymentDiscoveryComponent - with ResourceUpgradeFacet - ScriptDiscoveryComponent - with ResourceUpgradeFacet jboss-as plugin - ScriptDiscoveryComponent - with ResourceUpgradeFacet mysql plugin - MySqlDiscoveryComponent - WITHOUT ResourceUpgradeFacet (but the plugin was unmaintained before Steven actually contributed the code that changed the RK as a consequence of much larger feature set available in the plugin). This means that the only thing we should care about is the RK change in the MySqlDiscoveryComponent. I'd argue that before that change, Mysql plugin was not functional at all, so we don't have to worry about it. These would be the tests to smoke-test this: 1) Install JON 2.4.1 with all plugin-packs, inventory resources of as many different types as possible (ideally for each resource type in each plugin at least 1 resource). 2) Upgrade that installation to the latest RHQ code 3) Make sure no resource upgrade errors exist 4) Install latest RHQ using a fresh new database 5) Inventory the same resources as with JON 2.4.1 6) Compare the RHQ_RESOURCE tables from the 2 databases 7) The corresponding resources should have the same resource keys (the IDs most possibly won't match but that of course is not a problem).
Created attachment 527470 [details] RHQ_RESOURCES from 4.1
Created attachment 527473 [details] RHQ_RESOURCES from 2.4.1
verification failed at step #2 ... during the upgrade from JON 2.4.1 to RHQ latest (10/11/2011) build. attaching documentation: screenshot, text of error, upgrade log file, server log file
Created attachment 527476 [details] error of upgrade failure
Created attachment 527477 [details] text of upgrade error
Created attachment 527478 [details] dbupgrade log
Created attachment 527479 [details] server log
The upgrade errors are drift related. I think there has been some recent work on getting that work again. John, could you please push this bug back to ON_QA once you believe the upgrade should work again?
There was a dbupgrade failure on oracle due to duplicate constraint names. I reproduced, tested, and fixed locally. commit hash: 709da8b2c35b04dc252190b4c22166e2a5081c9d
verification failed in step #7 I was verifying on JON 3.0.0.CR1 what I did was : select resource_key from rhq_resource to file. Then cat file | sort | uniq -u > file_sorted. (for both databases) moving ON_DEV
Created attachment 532888 [details] diffrences between resource keys in JON2->3 and JON3
Some of the entries in the diff can be explained by the resource upgrade facets on some of the resource types: /opt/jboss-soa-p-5/jboss-as/bin/<script-name> -> <script-name> is due to the resource upgrade facet that changes the RK from an absolute path to a path relative to server's bin (http://git.fedorahosted.org/git?p=rhq/rhq.git;a=blob;f=modules/plugins/jboss-as-5/src/main/java/org/rhq/plugins/jbossas5/script/ScriptDiscoveryComponent.java;hb=HEAD#l99) vfsfile:/opt/jboss-soa-p-5/jboss-as/server/<profile>/deploy/<deployment-name> -> {<profile>}<deployment-name> is again due to a resource upgrade facet (http://git.fedorahosted.org/git?p=rhq/rhq.git;a=blob;f=modules/plugins/jboss-as-5/src/main/java/org/rhq/plugins/jbossas5/AbstractManagedDeploymentDiscoveryComponent.java;hb=HEAD#l126) What I can't explain are these: * the apparent sudden appearance of the RHQ tables in the new version - was the postgres plugin not deployed / configured properly in the old version? * /data/rhq/jon-server-3.0.0.CR1-upgrade/jon-server-3.0.0.CR1/jbossas/server/default - not sure how this could have disappeared in the new version. This seems to be a resource key of a JON server, which we definitely should be able to discover. Was the resource imported? * PersistAction, RedeliverMessagesAction, action, notificationAction - not sure what these are - what is the resource type and resource hierarchy? * boss.esb:category=MessageCounter,deployment=jbossesb.esb,service-category=JBossESB-Internal,service-name=DeadLetterService jboss.esb:category=MessageCounter,deployment=jbossesb.esb,service-category=JBossESB-Internal,service-name=RedeliverService jboss.esb:category=MessageCounter,deployment=jbpm.esb,service-category=JBossESB-Internal,service-name=JBpmCallbackService jboss.esb:deployment=jbossesb.esb,listener-name=JMS-DLQListener,service-category=JBossESB-Internal,service-name=DeadLetterService jboss.esb:deployment=jbossesb.esb,listener-name=redeliver-scheduled-listener,service-category=JBossESB-Internal,service-name=RedeliverService jboss.esb:deployment=jbpm.esb,listener-name=JMS-DCQListener,service-category=JBossESB-Internal,service-name=JBpmCallbackService Not sure what these are either
libor/lukas ... just checking on this ... is there an issue here? or is it resolved?
(In reply to comment #16) > /data/rhq/jon-server-3.0.0.CR1-upgrade/jon-server-3.0.0.CR1/jbossas/server/default > - not sure how this could have disappeared in the new version. This seems to be > a resource key of a JON server, which we definitely should be able to discover. > Was the resource imported? We can ignore this one. this item is rhq server on instance 2->3. I forgot to import it on the clean (3 only) one - I did't not realize it would change. > * PersistAction, RedeliverMessagesAction, action, notificationAction - not sure > what these are - what is the resource type and resource hierarchy? All these are ESB Actions :children of following ESB resources jboss.esb:deployment=jbossesb.esb,listener-name=JMS-DLQListener,service-category=JBossESB-Internal,service-name=DeadLetterService jboss.esb:deployment=jbossesb.esb,listener-name=redeliver-scheduled-listener,service-category=JBossESB-Internal,service-name=RedeliverService I've compared both databases once, focusing on ESB resources, and I see them in both now. In fact, I was playing with jon3clean instance a few times since I created diff (just start/stop). I don't see no issue here, except for one mystery: missing deployed ESB services/actions in jon3clean at one time.
Ok, so I think we can close this one. The mystery of missing resources should not affect their resource keys - they were just missing. If you are able to reproduce that Libor, please raise a separate BZ for it. I'm flipping this BZ to VERIFIED. Please change that if you need to do more with it.
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE
marking VERIFIED BZs to CLOSED/CURRENTRELEASE