(Click to open topic with navigation)
6.7.1 Enabling Personal Reservation Management
User, or personal, reservations can be enabled on a per QoS basis by setting the ENABLEUSERRSV flag as in the following example:
QOSCFG[titan] QFLAGS=ENABLEUSERRSV # allow 'titan' QOS jobs to create user reservations USERCFG[DEFAULT] QDEF=titan # allow all users to access 'titan' QOS ...
If set, end-users are allowed to create, modify, cancel, and query reservations they own. As with jobs, users may associate a personal reservation with any QoS or account to which they have access. This is accomplished by specifying per reservation accountable credentials as in the following example:
> mrsvctl -c -S AQOS=titan -h node01 -d 1:00:00 -s 1:30:00 Note: reservation test.126 created
As in the preceding example, a non-administrator user who wants to create a reservation must ALWAYS specify an accountable QoS with the mrsvctl -S flag. This specified QoS must have the ENABLEUSERRSVflag. By default, a personal reservation is created with an ACL of only the user who created it.
Example 6-23: Allow All Users in Engineering Group to Create Personal Reservations
QOSCFG[rsv] QFLAGS=ENABLEUSERRSV # allow 'rsv' QOS jobs to create user reservations GROUPCFG[sales] QDEF=rsv # allow all users in group sales to access 'rsv' QOS ...
Example 6-24: Allow Specific Users to Create Personal Reservations
# special qos has higher job priority and ability to create user reservations QOSCFG[special] QFLAGS=ENABLEUSERRSV QOSCFG[special] PRIORITY=1000 # allow betty and steve to use the special qos USERCFG[betty] QDEF=special USERCFG[steve] QLIST=fast,special,basic QDEF=rsv ...
6.7.2 Reservation Accountability
Personal reservations must be configured with a set of accountable credentials. These credentials (user, group, account, and so forth) indicate who is responsible for the resources dedicated by the reservation. If resources are dedicated by a reservation but not consumed by a job, these resources can be charged against the specified accountable credentials. Administrators are allowed to create reservations and specify any accountable credentials for that reservation. While end-users can also be allowed to create and otherwise modify personal reservations, they are only allowed to create reservations with accountable credentials to which they have access. Further, while administrators may manage any reservation, end-users may only control reservations they own.
Like jobs, reservation accountable credentials specify which credentials are charged for reservation usage and what policies are enforced as far as usage limits and allocation management is concerned. (See the mrsvctl command documentation for more information on setting personal reservation credentials.) While similar to jobs, personal reservations do have a separate set of usage limits and different allocation charging policies.
6.7.2.A Setting Reservation Default Attributes
Organizations can use reservation profiles to set default attributes for personal reservations. These attributes can include reservation aspects such as management policies, charging credentials, ACLs, host constraints, and time frame settings.
Allowing end-users the ability to create advance reservations can lead to potentially unfair and unproductive resource usage. This results from the fact that by default, there is nothing to prevent a user from reserving all resources in a given system or reserving resources during time slots that would greatly impede the scheduler's ability to schedule jobs efficiently. Because of this, it is highly advised that sites initially place either usage or allocation based constraints on the use of personal reservations. This can be achieved using Moab Accounting Manager (see the Moab Accounting Manager Administrator Guide).
6.7.4 Reservation and Job Binding
Moab allows job-to-reservation binding to be configured at an administrator or end-user level. This binding constrains how job to reservation mapping is allowed.
6.7.4.A Constraining a job to only run in a particular reservation
Jobs may be bound to a particular reservation at submit time (using the RM extension ADVRES) or dynamically using the mjobctl command (See Job to Reservation Mapping.). In either case, once bound to a reservation, a job may only run in that reservation even if other resources may be found outside of that reservation. The mjobctl command may also be used to dynamically release a job from reservation binding.
Example 6-25: Bind job to reservation
> mjobctl -m flags+=advres:grid.3 job1352
Example 6-26: Release job from reservation binding
> mjobctl -m flags-=advres job1352
6.7.4.B Constraining a Reservation to Only Accept Certain Jobs
Binding a job to a reservation is independent of binding a reservation to a job. For example, a reservation may be created for user "steve." User "steve" may then submit a number of jobs including one that is bound to that reservation using the ADVRES attribute. However, this binding simply forces that one job to use the reservation, it does not prevent the reservation from accepting other jobs submitted by user "steve." To prevent these other jobs from using the reserved resources, reservation to job binding must occur. This binding is accomplished by specifying either general job binding or specific job binding.
General job binding is the most flexible form of binding. Using the BYNAME attribute, a reservation may be created that only accepts jobs specifically bound to it.
Specific job binding is more constraining. This form of binding causes the reservation to only accept specific jobs, regardless of other job attributes and is set using the JOB reservation ACL.
Example 6-27: Configure a reservation to accept only jobs that are bound to it
> mrsvctl -m flags+=byname grid.3
Example 6-28: Remove general reservation to job binding
> mrsvctl -m flags-=byname grid.3
Example 6-29: Configure a reservation to accept a specific job
> mrsvctl -m -a JOB=3456 grid.3
Example 6-30: Remove a specific reservation to job binding
> mrsvctl -m -a JOB=3456 grid.3 --flags=unset