Re: [Condor-users] Rank policy

[Ian Stokes-Rees <ijstokes@xxxxxxxxxxxxxxxxxxx>]

Who produces condor.pm?  Does OSG have any hand in it?  It would be nice to have as default the ability to include VO (group) information if this is available added to the job classad, since otherwise I presume I need to reapply the patch after every upgrade.

Cheers,

Ian

Dan Bradley wrote:

Ian Stokes-Rees wrote:
  

I would like to setup Condor with a policy which states something 
(conceptually) along the lines of:

1. Execute all jobs from user X first, if they exist
2. Execute all jobs from members of group Y, if they exist
3. Service all other user jobs.

Am I correct in thinking this needs to be embedded all in the RANK 
statement for STARTD (i.e. in the main $C_L/etc/condor_config file)?
    

Yes, RANK is a good policy _expression_ to use for this type of policy.  
Do you want jobs to be killed in case of higher ranked jobs becoming 
available?  If so, that's the default behavior.  If not, then use 
MaxJobRetirementTime to specify how long jobs should be allowed to 
finish normally before being killed.

  

The follow on question is what is the standard way to identify a job 
as belonging to a particular group?
    

One common method is to stuff something into the job ClassAd that 
declares the group.  In OSG, there are various condor.pm hacks to do 
this.  One that I have used described on the following page under 
"Adding OSG VO information to the job ClassAd":

http://www.hep.wisc.edu/~dan/condor_jobmanager_hacks/

--Dan

_______________________________________________
Condor-users mailing list
To unsubscribe, send a message to condor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/condor-users

The archives can be found at: 
https://lists.cs.wisc.edu/archive/condor-users/
  

-- 
Ian Stokes-Rees, Research Associate
SBGrid, Harvard Medical School
http://sbgrid.org