Red Hat Bugzilla – Bug 855449
getSubmissionID by qdate with scan mode "AFTER" does not work unless the qdate supplied is an exact match of an existing qdate
Last modified: 2013-03-06 13:45:42 EST
Description of problem: It seems empirically that qdate must be an exact match when scan mode is AFTER for getSubmissionsID(). My expectation was that qdate=0 with mode = AFTER should return all known submissions. Reproducers and such to follow.
It may be the case that AFTER never works, actually, regardless of match.
condor-aviary-7.8.3-0.1.el5 100% reproducible 1) Install condor with condor-aviary and submit multiple jobs. 2) In my testing, I configured Aviary to use the locator so I have to retrieve the endpoint for the QUERY_SERVER (but known endpoints might be easier for testing) # cd /usr/share/condor/aviary/ # export PYTHONPATH=`pwd`/module:$PYTHONPATH # ./locator.py --type=CUSTOM CUSTOM | QUERY_SERVER | query@somehost.redhat.com | http://somehost.redhat.com:39903/services/query/ 3) Get the list of submissions to confirm that Aviary knows about the jobs: # ./submissions.py --u=http://somehost.redhat.com:39903/services/query/getSubmissionSummary [(SubmissionSummary){ id = (SubmissionID){ name = "cat" owner = "admin" qdate = 1343740287 } status = (Status){ code = "OK" } completed = 4 held = 0 idle = 0 removed = 3 running = 0 suspended = 0 transferring_output = 0 } ... 4) Run a search with scan mode BEFORE and a large qdate. I used 2000000000 because it's out in the future, so everything is "before". This works. [root@somehost aviary]# ./submission_ids.py --qdate=2000000000 --mode=BEFORE --size=1024 --u=http://localhost:39903/services/query/getSubmissionID (reply){ ... } 5) Run a search with scan mode AFTER and use 0. This fails with no data: # ./submission_ids.py --qdate=0 --mode=AFTER --size=1024 --u=http://localhost:39903/services/query/getSubmissionID (reply){ remaining = 0 } 6) Search with a value from the original submission list, just in case Aviary can handle an existing date but not 0. Also fails: ]# ./submission_ids.py --qdate=1343740287 --mode=AFTER --size=1024 --u=http://localhost:39903/services/query/getSubmissionID (reply){ remaining = 0 } Expected results: For scan mode AFTER, Aviary should handle any legitimate qdate value including 0. If there are jobs in the history that have qdate >= target value, they should be returned. According to code in the test program /usr/share/condor/aviary/submission_ids.py, the legal range for qdate is 0 to maxint: if opts.qdate and (long(opts.qdate) > sys.maxint): print 'Invalid input: Qdate is larger than system max integer' exit(1) I am assuming that negatives are legal, and have the same effect as 0.
Tested on RHEL 5.9/6.4 x x86_64/i386 with condor-7.8.7-0.6.el6_3.x86_64 condor-aviary-7.8.7-0.6.el6_3.x86_64 condor-classads-7.8.7-0.6.el6_3.x86_64 condor-wallaby-base-db-1.25-1.el6_3.noarch condor-wallaby-client-5.0.4-1.el6_3.noarch condor-wallaby-tools-5.0.4-1.el6_3.noarch python-condorutils-1.5-6.el6.noarch python-qpid-0.18-4.el6.noarch python-qpid-qmf-0.18-12.el6_3.x86_64 python-wallabyclient-5.0.4-1.el6_3.noarch qpid-cpp-client-0.18-12.el6_3.x86_64 qpid-cpp-server-0.18-12.el6_3.x86_64 qpid-qmf-0.18-12.el6_3.x86_64 qpid-tools-0.18-7.el6_3.noarch ruby-condor-wallaby-5.0.4-1.el6_3.noarch ruby-qpid-qmf-0.18-12.el6_3.x86_64 ruby-wallaby-0.16.1-2.el6.noarch wallaby-0.16.1-2.el6.noarch wallaby-utils-0.16.1-2.el6.noarch and it works. --> 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