Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Services of manually added sub-servers are not discovered|
|Product:||[Other] RHQ Project||Reporter:||David Vrzalik <dvrzalik>|
|Component:||No Component||Assignee:||John Mazzitelli <mazz>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Sunil Kondkar <skondkar>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-09-02 03:26:08 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description David Vrzalik 2008-10-22 08:58:00 EDT
Service discovery is never executed for a server manually added under another server. To be more precise, RuntimeDiscoveryExecutor.discoverForResource(..) is executed for the nested server just once right after it is added but it returns immediately since the parent server is not in the COMMITTED state yet. Further, when common platform resource discovery is triggered, RuntimeDiscoveryExecutor iterates trough all platform's servers, calls discoverForResource on them and on their newly found sub-components, while previously manually added server is left behind.
Comment 1 Joseph Marques 2009-04-28 04:24:41 EDT
if this is still an issue today, it should get high priority. we don't want to give people headaches just because we weren't able to auto-discover there resource.
Comment 2 Charles Crouch 2009-08-06 09:40:28 EDT
With QA to try to reproduce
Comment 3 Red Hat Bugzilla 2009-11-10 15:21:44 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1006
Comment 4 Corey Welton 2010-08-18 10:57:12 EDT
Moved to ON_QA with the expectation that this is resolved. if it is not, please reopen. Otherwise close.
Comment 6 John Mazzitelli 2011-03-15 12:08:28 EDT
this is still a problem. verified on latest 4.0 beta1. get a plugin with four levels deep of resources and you'll see it (top server, direct child, grandchild, great-grandchild). workaround - use "discovery --resourceId" feature to force the discovery.
Comment 7 John Mazzitelli 2011-03-15 23:32:55 EDT
Created attachment 485634 [details] skeleton plugin to test with attaching a skeleton plugin jar with source that can test this. the plugin jar does nothing except attempt to build the following hierarchy: + My Top Server ++ My Child +++ My GrandChild 1 ++++ My GreatGrandChild 1 ++++ My GreatGrandChild 2 +++ My GrandChild 2 ++++ My GreatGrandChild 1 ++++ My GreatGrandChild 2 Note that you must manually add the "My Child" resource after My Top Server is auto-discovered. The grandchild and greatgrandchild services are autodiscovered. My Top Server is a server, the others are services. Notice the 4-level deep hierachy. I think this is required to test this issue. Because after manually importing My Child, a service scan discovery will find the My GrandChild 1/2 services. However, its the 4th level deep - the great grand child services, that cannot be auto-discovered. You have to use the "discovery --resourceId" mechanism to force those services to be found.
Comment 8 John Mazzitelli 2011-03-16 16:41:16 EDT
Created attachment 485833 [details] patch to fix the issue
Comment 9 John Mazzitelli 2011-03-16 16:44:13 EDT
I think this is finally fixed. commit 8a4b075dbb23c09759ea64db09346e6f80bd7328 To test: 1) deploy the attached plugin to your RHQ Server 2) update your agent's plugins to pick up the new plugin and wait for the new Top Server to be autodiscovered and placed into your auto-discovery queue 3) import Top Server 4) go to Top Server and manually add a "Child" resource 5) refresh the browser window after a while (60 seconds or so?) and see that you have a hierarchy under Top Server that is described in comment #7
Comment 10 Sunil Kondkar 2011-06-09 05:48:34 EDT
Verified on build123 (Version: 4.1.0-SNAPSHOT Build Number: a6d2d56) Deployed and imported the attached skeleton plugin. Navigated to the inventory tab of the top server and imported child resource. The hierarchy under Top Server is displayed. Please refer the attached screenshot. Marking as verified.
Comment 12 Heiko W. Rupp 2013-09-02 03:26:08 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.