Description of problem: Search server polls the database on a configurable time, default is 5 minutes. This means that when a system is registered, it will not be picked up by search server until the next triggering of this indexing task. This bug is to note work added to allow a means of system registrations to trigger indexing of new data immediately. Version-Release number of selected component (if applicable): All 5.3 ISOs prior to and including 4/19/09 How reproducible: Always Steps to Reproduce: 1. Register a new system 2. Search for the new system Actual results: System isn't found, until you wait 5 minutes then re-search. Expected results: System should be available within seconds after a registration. Additional info:
Below two commits in VADER fix this. commit 6469c552728ffc004afa97cd570ccea8023ddf06 Search server adding a xmlrpc call that will allow updates to be triggered immediately This will be leveraged by the backend. When a system is registered a xmlrpc message will be sent to search server, causing it to update the system indexes. commit a81f21c046b151fc7f3d4ef2aab6aae604ffe6c0 When a new system is registered it will notify search service Adding hook in backend to send a xmlrpc message to search-server, tells search-server to look up servers and index new entries. Note: This is not guaranteed, search-server may ignore this if too many requests come in. Index request limiting is handled by the quartz trigger name. Only one trigger per index will be allowed to impact scheduling, any other requests received before the intial trigger has finished will be dropped.
Missed adding "search_notify.py" to the RPM, below commit takes care of this. http://git.fedorahosted.org/git/?p=spacewalk.git;a=commit;h=bd6ab324ac7d4736021bfcedea73558f06d24774
verified. looks like this working. Satellite-5.3.0-RHEL5-re20090529.0-i386-embedded-oracle.iso
Stage validated with Satellite-5.3.0-RHEL5-re20090820.1: run rhnreg_ks and when I hit Search in the WebUI two seconds later, the system was found. Moving to RELEASE_PENDING.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1434.html