-Restrictions on what jobs will run on a given resource are
-enforced by only starting jobs that meet specific constraints,
-and these constraints are specified as part of the configuration.
+Sometimes you may want to limit a set of machines to either
+
+1: only run jobs from a specific user or set of users, or
+
+1: only allow ONE active user per execute node, so that on a execute node using partitionable slots, if UserA lands on machine Execute1 and uses say 2
+out of 10 cpus, then UserA is also allowed to claim more slots on
+that machine and UserB would not be allowed. Once UserA jobs have completed on Execute1, then if UserB landed on that machine, only userB would then be allowed to claim additional slots/resources on Execute1.
+
+We give recipes for each of the above scenarios below.
+
+{subsection: Only run jobs from a specific user or set of users}
To specify that a given machine should only run certain users' jobs,
and always run the jobs regardless of other activity on the machine,
@@ -13,26 +21,22 @@
(User == "userbar@baz.edu") )
{endcode}
-A more likely scenario is that the machine is restricted to run
-only specific users' jobs, contingent on the machine not having
-other interactive activity and not being heavily loaded.
-The following entries are in the machine's HTCondor configuration file.
-Note that extra configuration variables are defined to make
-the START variable easier to read.
+{subsection: Only allow ONE active user per execute node}
+
+Imagine you only want to allow ONE active user per execute machine on machine configured to use partitionable slots. This may be a security requirement at some sites. So the idea is if UserA lands on machine Execute1 and uses say 2
+out of 10 cpus, then UserA is also allowed to claim more slots on
+that machine and UserB would not be allowed. Once UserA jobs have completed on Execute1, then if UserB landed on that machine, only userB would then be allowed to claim additional slots/resources on Execute1.
+
+To accomplish this on HTCondor v8.4 or above, ppending the following into the condor_config file(s) of the machines where you only want one user per node:
{code}
-# Only start jobs if:
-# 1) the job is owned by the allowed users, AND
-# 2) the keyboard has been idle long enough, AND
-# 3) the load average is low enough OR the machine is currently
-# running an HTCondor job, and would therefore accept running
-# a different one
-AllowedUser = ( (User == "userfoo@baz.edu") || \
- (User == "userbar@baz.edu") )
-KeyboardUnused = (KeyboardIdle > $(StartIdleTime))
-NoOwnerLoad = ($(CPUIdle) || (State != "Unclaimed" && State != "Owner"))
-START = $(AllowedUser) && $(KeyboardUnused) && $(NoOwnerLoad)
+START = ( $(START) ) && \
+ ifThenElse(PartitionableSlot=?=True && UpdatesLost=!=UNDEFINED, \
+ size(ChildRemoteUser)==0 || member(User,ChildRemoteUser), \
+ RemoteUser=?=UNDEFINED || User=?=RemoteUser)
{endcode}
-To configure multiple machines to do so, create a common
-configuration file containing this entry for them to share.
+The expression above leverages the fact that =User= is an attribute in the job classad that identifies the submitting user.
+Attribute =RemoteUser= is in a slot ad, and equals the user of whomever claimed the slot.
+Attribute =ChildRemoteUser= is in the partitionable slot ad in the collector, and will be
+a classad list containing the all =RemoteUser= values of all the dynamic slots created under that partitionable slot.
