Bug 535833 (RHQ-2489)

Summary: Auto discovery queue getting confused
Product: [Other] RHQ Project Reporter: Galder ZamarreƱo <galder.zamarreno>
Component: No ComponentAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: high    
Version: 1.3CC: cwelton
Target Milestone: ---Keywords: SubBug
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-2489
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-13 19:57:16 UTC Type: ---
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:    
Bug Blocks: 565628    

Description Galder ZamarreƱo 2009-11-05 17:29:00 UTC
<galderz> i have a CacheManager who's name is based around the ip address to which it bounds
<galderz> imagine that you start and bounds to localhost:1234
<galderz> that's the name that I see in the auto-discovery queue
<galderz> however, if I shutdown the manager and start it again, it has a diff name, localhost:3456
<galderz> but the auto discovery queue still shows the old name
<galderz> importing works fine, it seems to link up to localhost:3456 but the name is incorrectly displayed
<galderz> pilhuhn, this looks to me a bug in the auto-discovery queue
<galderz> it should figure out that the name is different
<pilhuhn> yeah - this is a know limitiation -- the AD queue should clean up
<galderz> how can I clean up the auto discovery queue?
<pilhuhn> It can't figure that out by itself, as the one 1234 may come back
<pilhuhn> but there should be a way to mark the 1234 one as "no longer needed"
<galderz> it's a pretty bad limitation, v confusing to the user
<pilhuhn> yes
<pilhuhn> I agree
<galderz> so, if I see it again, how can I at least get around it?
<galderz> i wanna show the ispn users the correct cache manager instance in the queue
<galderz> clean up the queue somehow?
<galderz> discard the AD queue?
<pilhuhn> you may try to import 1234 and then after this is done, go to resource hub and directly un-import it again
<pilhuhn> could you please write an RHQ jira ?
<galderz> i did that actually
<galderz> and then when i started a new cache manager, it would never appear in the queue!
<pilhuhn> ah cool :) ccrouch1 is surely listening :)
<galderz> that AD queue looks v fragile to me
<pilhuhn> the new manager may be just an issue of scan time - either initiate a manual autodiscovery or wait some time
<galderz> ok, i'll modify that too for the demo

Comment 1 Red Hat Bugzilla 2009-11-10 21:05:24 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2489


Comment 2 wes hayutin 2010-02-16 16:54:45 UTC
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug

Comment 3 wes hayutin 2010-02-16 17:00:08 UTC
making sure we're not missing any bugs in rhq_triage

Comment 4 Corey Welton 2010-09-13 19:57:04 UTC
Closing - per 9-Sep triage.  Can be reopened if considered a serious concern.