[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-users] controlling job preemption by user's Unix group



> I am strongly suspecting this isn't possible but....

I think you can do what you want, maybe but not with the level of
automation you seek.

Here's what I'd do...

> I am presuming that if I could somehow automate setting their Unix
> groups I can set a formula in PREEMPTION_REQUIREMENTS that ignores job
> run time and just looks at group & machine-owner but I'm not
> sure how I
> can add the "but only if no other resources are available on any other
> host" part.  (Frankly, I'm horrible at writing Condor config
> equations :)
>
> Any hints or tips would be greatly appreciated.

On submit I'd tag your clusters with a group string:

        +MyGroup = "foo"

And on your machines set the RANK to take in to account MyGroup:

        RANK = ( \
                  (("foo =?= TARGET.MyGroup) * 100) + \
                  (("bar =?= TARGET.MyGroup) * 99) + \
                  (("moo =?= TARGET.MyGroup) * 98) \
                )

(My brackets might not be balanced in the above example, double check
before using)

That gives foo the top rank on the machine, followed by bar, then boo.

Now sort your preempt candidates based on RANK. This is pretty close to
how I do it:

##  The rank expressions used by the negotiator are configured below.
##  This is the order in which ranks are applied by the negotiator:
##    1. NEGOTIATOR_PRE_JOB_RANK
##    2. rank in job ClassAd
##    3. NEGOTIATOR_POST_JOB_RANK
##    4. cause of preemption (0=user priority,1=startd rank,2=no
preemption)
##    5. PREEMPTION_RANK

##  The NEGOTIATOR_PRE_JOB_RANK expression overrides all other ranks
##  that are used to pick a match from the set of possibilities.
##  Try running jobs on machines that are unclaimed. Also try putting
##  jobs on machines that are in the state Owner+Idle because these
machines
##  may just have very strict START requirements.
NEGOTIATOR_PRE_JOB_RANK =  (((Activity =?= 'Owner') * (State =?=
'Idle')) * 1000000000) + ((Activity =?= 'Unclaimed') * 100000000)

##  The NEGOTIATOR_POST_JOB_RANK expression chooses between
##  resources that are equally preferred by the job.
##
##  Break ties by looking for machines that have Idle longer than others
##  and use them first. Also try and use faster machines before slower
##  machines and assign jobs to separate machines before we start
putting
##  two jobs on a machine.
NEGOTIATOR_POST_JOB_RANK = (((Activity =?= 'Owner') * (State =?=
'Idle')) * 1000000000) + ((Activity =?= 'Unclaimed') * 100000000) +
(KFlops * 0.001) - (SlotID * 10)

##  The negotiator will not preempt a job running on a given machine
##  unless the PREEMPTION_REQUIREMENTS expression evaluates to true
##  and the owner of the idle job has a better priority than the owner
##  of the running job. Another occasion where negotiator-initiated
##  preemption could occur is when the startd RANK expression
##  evaluates to a higher value with an idle job than the CurrentRank
##  registered at the execute. CurrentRank is calculated only once
##  when the job starts. It is not updated afterwards.
PREEMPTION_REQUIREMENTS = True

##  The PREEMPTION_RANK expression is used in a case where preemption
##  is the only option and all other negotiation ranks are equal.  For
##  example, if the job has no preference, it is usually preferable to
##  preempt a job with a small ImageSize instead of a job with a large
##  ImageSize.  The default is to rank all preemptable matches the
##  same.  However, the negotiator will always prefer to match the job
##  with an idle machine over a preemptable machine, if all other
##  negotiation ranks are equal.
##
##  Preempt machines that have users with lower rank on them. This means
##  high ranking jobs preempt the lowest ranking jobs  first and then
the
##  medium ranking jobs and so on. We also prefer to preempt other users
##  jobs rather than our own.
PREEMPTION_RANK = 1000000000 - TARGET.Rank - ((TARGET.RemoteOwner =?=
MY.RemoteOwner) * 100)


That's how I'd solve it. I suspect there's an elegant solution that can
be implemented with Group Quota's as well. But I'm not well versed on
how to use Group Quota's I'm afraid. See:

http://www.cs.wisc.edu/condor/manual/v7.2/3_4User_Priorities.html#24014

-  Ian

Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution,  or copying  of this message, or any attachments, is strictly prohibited.  If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments.  Thank you.