Re: [HTCondor-users] Prioritizing jobs using the RANK expression on the execute point (EP) side

[Todd L Miller <tlmiller@xxxxxxxxxxx>]

>  * Despite this, Rank doesnʼt seem to influence job start order in this
>    setup

	As I understand it, a machine's RANK will not: the negotiator 
considers users' resource requests in priority order, and assigns resource 
as it find matches.  It's only if two matching machines are available at 
the same time that RANK matters, and then the higher-RANK machine will be 
assigned.

	Setting CLAIM_WORKLIFE to 0 will force the negotiator to decide 
who gets each resource each time a job finishes; this will only help if 
the problem is that user U has taken all the resources and user V doesn't 
get any even after a U-job has finished.

> Do you have any further suggestions on how to enforce preference for 
> jobs from this group (the owners of these machines)?

	Our local pool has a policy for owned machines, but it depends on 
preemption.  The general idea is that the owners' job(s) preempt non-owner 
jobs on the owned machines, but that non-owner jobs must explicitly opt-in 
to being run on resources that might preempt that any time.  In this way, 
you can continue to offer assurances to submitters that their jobs won't 
be preempted, with the carrot of being able to use otherwise-idle time on 
the owned nodes.

	The implementation of this policy is too complicated for an email, 
but if you're interested, I can try to get it written up as worked-out 
example somewhere.

	The other option depends on how tightly tied to their specific 
machines your owners are; we're working on a feature that would allow you 
to say things like "this group of submitters always priority access to 24 
CPUs and 48 GBs of RAM" without naming a specific machine (or machines). 
This means those resources would be available to that group even if their 
particular machine is down for maintenance or otherwise unavailable.

-- ToddM