Bug 753822

Customer considerations and impact:

The current OOTB default is provided in the QMF schedd plug-in code as
QMF_PUBLISH_SUBMISSIONS = True
Also, the base configuration does not add the JOB_SERVER to the DAEMON_LIST 
although it is defined.

Recommend the following:

1) Code change within the condor_job_server to halt activation if
QMF_PUBLISH_SUBMISSIONS = True
This will avoid confusion from having two *redundant* job servers active 
in the same QMF object space.

2) Modify 60condor-qmf.config to add/uncomment:
	QMF_PUBLISH_SUBMISSIONS = False
	DAEMON_LIST = $(DAEMON_LIST), JOB_SERVER

3) Release Note
	"The default configuration of the QMF Job Server used by cumin has 
	been changed. The previous default was to use an embedded QMF Job 
	Server object managed within a schedd plug-in component. The default 
	configuration now launches a standalone daemon (condor_job_server) and
	disables the submission publishing from within the plug-in's embedded 
	Job Server. Grid users using the old default should note that with the 
	new default configuration, job details will now be available for jobs 
	that have been completed or removed from the queue."

4) Possibly revise section of MCIG <4.1.1. Job Server Configuration> to note
or emphasize the new default.

No base-db changes required since there is no feature that specifically activates the current default of QMF_PUBLISH_SUBMISSIONS = True.

Validation techniques:
- 1 jobserver object listed via qpid-tool where only 1 schedd has been deployed
- jobserver QMF object contains a "jobserver" prefix to schedd host, not "scheduler"
- full job ads can be retrieved using QMF from a job that has been committed to history (confirmed using condor_history)

    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:
Release Note:
"The default configuration of the QMF Job Server used by cumin has been changed. The previous default was to use an embedded QMF Job Server object managed within a schedd plug-in component. The default configuration now launches a standalone daemon (condor_job_server) and disables the submission publishing from within the plug-in's embedded Job Server. Grid users using the old default should note that with the new default configuration, job details will now be available for jobs that have been completed or removed from the queue."

(In reply to comment #5)
> Validation techniques:
> - 1 jobserver object listed via qpid-tool where only 1 schedd has been
> deployed
> - jobserver QMF object contains a "jobserver" prefix to schedd host, not
> "scheduler"
> - full job ads can be retrieved using QMF from a job that has been committed
> to history (confirmed using condor_history)

Everything seems ok, only one thing I don't understand, what does it mean
jobserver QMF object contains a "jobserver" prefix to schedd host, not "scheduler"?
I compare schemas in qpid-tool on old version with schema on new version and it seems the same for me.

Clarification and elaboration of comment #5:

The QMF implementation allows the schedd plugin to act as both a "scheduler" and a "jobserver". In this scenario, its QMF object id should contain the string "scheduler" in it anywhere. In the opposite scenario, you will not see that.

%qpid-tool
Management Tool for QPID
qpid: list jobserver
Management Object Types:
    ObjectType       Active  Deleted
    ==================================
    com.redhat.grid:jobserver  1       0
qpid: show com.redhat.grid:jobserver

Tested with:
condor-qmf-7.8.8-0.4

Tested on:
RHEL6 i386,x86_64
RHEL5 i386,x86_64

second point verification: The scheduler name is not present in the show command

SCHEDD_NAME = scheduler@$(FULL_HOSTNAME)

schedd plugin:
qpid: show 214
...
    Name                              scheduler@host

jobserver process:
qpid: show 236
...
    Name                              host

>>> verified

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0564.html