Re: [HTCondor-users] Matching Problem With Custom ClassAdd

[Todd Tannenbaum <tannenba@xxxxxxxxxxx>]

On 10/22/2014 5:28 PM, Frank Berghaus wrote:
> Suggestions:
>
>      Condition                         Machines Matched    Suggestion
>      ---------                         ----------------    ----------
> 1   VMType is "atlas-worker"          0                   MODIFY TO
> "atlas-worker"
> 2   Target.Arch == "x86_64"           4
> 3   ( TARGET.OpSys == "LINUX" )       4
> 4   ( TARGET.Disk >= 10000000 )       4
> 5   ( TARGET.Memory >= 29500 )        4
> 6   ( TARGET.HasFileTransfer )        4
>
> These two strings ("atlas-worker") look the same, yet the match fails.

I think suggestion from -better-analyze is a bug, and a red herring.

Most likely the real reason your job is not matching is because some 
condition in the machine requirements (aka the START expression in your 
condor_config) is not being met.  Recall that for a match to happen, 
both the job requirements and the machine requirements need to evaluate 
to True.  By default, condor_q -analyze only tries to analyze your job's 
requirements expression.  I suggest you do a "condor_status" and pick an 
unclaimed slot that you think your job should match with.  Lets say it 
is called 'slot1@xxxxxxx'.  And lets say your job is job id 50.0.  Try 
entering the following command:

  condor_q -analyze -reverse -machine slot1@xxxxxxx 50.0

Doing the above may identify a clause in the requirements of the machine 
that is causing the machine to dislike your job.

Doing a 'condor_q -analyze -reverse -machine xxxx' has solved many 
matching mysteries for me.

Hope the above helps,
Todd