Re: [Condor-users] condor_rm -constraint bug?

[David Brodbeck <brodbd@xxxxxxxxxxxxxxxx>]

On Mar 10, 2009, at 8:40 PM, Matthew Farrellee wrote:

> David Brodbeck wrote:
> > The answer to this is probably "it's fixed in 7.x", but I thought I'd
> > mention it here just in case.  One of my users reports that condor_rm
> > interprets constraints differently from condor_q.  He was trying to
> > remove the idle jobs from a job cluster.  We're running v6.8.8.
> >
> > condor_q jdoe -constraint JobStatus==1
> >
> > ...worked as intended, listing only the idle jobs.  But...
> >
> > condor_rm jdoe -constraint JobStatus==1
> >
> > ...removed the entire job cluster.
>
> condor_rm jdoe -constraint JobStatus==1 is removing all jobs with
> JobStatus==1 AND all jobs owned by jdoe. He probably noticed that the
> cluster was gone, because all his jobs were gone.

OK, that makes sense.  Thanks.   After a bit more playing, it looks  
like I want to stick the username into the constraint instead, e.g.:
-constraint '(Owner=="jdoe" && JobStatus==1)'

But that still leaves me wondering why condor_q and condor_rm differ  
in this behavior.  It would be nice to be able to "test run"  
constraints in condor_q before using them with condor_rm. Having two  
commands that take the same syntax interpret it differently seems  
counter-intuitive.
On carefully reading the manpages, it seems that condor_rm is behaving  
as documented, and condor_q's behavior is incorrect.  condor_q's  
interpretation strikes me as safer and more intuitive, though.  It's a  
little odd to have a "-constraint" flag *enlarge* the number of jobs  
involved instead of, well, constraining it. ;)

--

David Brodbeck
System Administrator, Linguistics
University of Washington