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
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/