Re: [HTCondor-users] HTCondor flock and Negotiator interval

[Greg Thain <gthain@xxxxxxxxxxx>]

On 8/29/19 12:21 PM, Vikrant Aggarwal wrote:
> Hello Experts,
>
> I want to confirm my understanding about the behavior of requirements 
> and flock_to list:
>
> D is the primary cluster of submitter node which shows up in 
> "condor_host". B, C and A are the pools to which submitter node can 
> flock.
>
> FLOCK_TO = B, C, A
>
> Requirements = ( (MachineOwner=="A") Â|| Â(MachineOwner=="B") Â|| 
> Â(MachineOwner=="C") Â|| (MachineOwner=="D")
>
> My understanding:
>
> - Irrespective of the order it always tries first to find slot in 
> primarly pool in this case D.


This is correct.


> - If any pool mentioned in flock_to list but not in requirement that 
> will not be considered.


Once condor starts trying to flock, it just does normal matchmaking -- 
if the job's requirements expression matches the slot's (and vice-versa) 
in the remote pool, that machine is eligible to run the job.


> If my above understanding is correct then how can I force the submit 
> box to try running the job on pool D for 30 mins and if the slots are 
> not available after 30mins then move to the other pools mentioned in 
> requirements.


Probably the easiest way to do this is explicitly in the job's requirements:

Requirements = (Collector_host_string = "D") || ((time() - QDate) > 1800)

This method may create a lot of autoclusters if you have a large number 
of jobs, which can slow down negotiation.

-greg