Description of problem: This request is related to scale for 1.3.2 Management Console. The goal is to allow wallaby related components to use a separate qpid broker, so that starts of the wallaby consoles do not cause a republish event on the same broker as cumin. The QMF traffic that cumin receives on such an event can be an enormous, temporary burst which may adversely effect performance under medium scale. Currently, it is not possible to specify a separate qpid broker from that used by condor and cumin.
The configd now supports parameters of the configd.qmf_broker_* variety. If one of these is defined, it will be used over the global version. Fixed on master.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: C: It can be useful to have the remote configuration feature communicate on a different broker than a broker with heavier traffic or a more complex configuration C: The remote configuration feature can use different authentication mechanisms and not have to worry about traffic congestion C: The condor_configd now recognizes CONFIGD.QMF_BROKER_* params. These parameters will override those set without the CONFIGD. prefix. R: It is possible to run the remote configuration feature on a separate broker
Tested on RHEL 5.6 x i386/x86_64 as cumin/cumin's qpidd/wallaby store and RHEL 4.9 x i386/x86_64 as wallaby's qpidd. All nodes are sesamized and wallaby-clients. Tested with: python-condorutils-1.4-6.el5 wallaby-0.10.4-2.el5 condor-7.4.5-0.7.el5 qpid-cpp-server-0.7.946106-27.el5 rh-tests-distribution-MRG-Messaging-qpid_common-1.6-56 ruby-wallaby-0.10.4-2.el5 python-wallabyclient-3.9-3.el5 condor-wallaby-base-db-1.5-2.el5 condor-wallaby-tools-3.9-3.el5 condor-wallaby-client-3.9-3.el5 qpid-tools-0.7.946106-12.el5 qpid-cpp-client-0.7.946106-27.el5 python-qpid-0.7.946106-15.el5 wallaby-utils-0.10.4-2.el5 condor-qmf-7.4.5-0.7.el5 qpid-cpp-server-0.7.946106-27.el4 python-wallabyclient-3.9-3.el4 python-qpid-0.7.946106-15.el4 condor-wallaby-client-3.9-3.el4 qpid-tools-0.7.946106-12.el4 rh-tests-distribution-MRG-Messaging-qpid_common-1.6-56 qpid-cpp-client-0.7.946106-27.el4 python-condorutils-1.4-6.el4 condor-7.4.5-0.7.el4 condor-qmf-7.4.5-0.7.el4 and it works. -->VERIFIED
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1 @@ -C: It can be useful to have the remote configuration feature communicate on a different broker than a broker with heavier traffic or a more complex configuration +Running the remote configuration feature on a separate broker is now supported. This is useful to alleviate congestion in cases when one broker is experiencing heavy traffic. Additionally, the remote configuration feature can be configured to use various authentication mechanisms. This feature can be configured by editing the parameters which begin with "CONFIGD.QMF_BROKER_[parameter]" in the condor_configd configuration file.-C: The remote configuration feature can use different authentication mechanisms and not have to worry about traffic congestion -C: The condor_configd now recognizes CONFIGD.QMF_BROKER_* params. These parameters will override those set without the CONFIGD. prefix. -R: It is possible to run the remote configuration feature on a separate broker
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/RHBA-2011-0217.html