Access Specifiers, Variants, Template Job Class

Now I will explain three additional aspects of job classes: Access specifiers - They allow deviation from a derived job class during or after submission of a job. Job class variants - They will help to keep the effort in configuring job classes small. The template job class - This job class might be used to enforce settings for all other job classes in a system.

Access Specifiers to Allow Deviation

Access specifiers are character sequences that can be added to certain places in job class specifications to allow/disallow operations that can be applied to jobs that are derived from that job class. They allow you to express, for instance, that job options defined in the job class can be modified, deleted or augmented when submitting a job derived from a job class. This means the job class owner can control how the job class can be used by regular users being allowed to derive jobs from this job class. This makes using job classes simple for the end user (because of a restricted set of modifications). It also avoids errors as well as the need to utilize Job Submission Verifiers for checking on mandatory options.

Per default, if no access specifiers are used, all values within job classes are fixed. This means that jobs that are derived from a job class cannot be changed. Any attempt to adjust a job during the submission or any try to change a job after it has been submitted (e.g. with qalter) will be rejected. Also managers are not allowed to change the specification of values defined in a job class when submitting a job derived from the job class.

To soften this restriction, job class owners and users having the manager role can add access specifiers to the specification of a job class to allow deviation at certain places. Access specifiers might appear before each value of a job template attribute and before each entry in a list of key or key/value pairs. The preceding access specifier defines which operations are allowed with the value that follows.

  • Values that are tagged with the {-} access specifier are removable. If this access specifier is used within list based attributes then removal is only allowed if the list itself is also modifiable. If all list entries of a list are removable then also the list itself must be removable so that the operation will be successful.
  • Values that are prefixed with the {~} access specifier can be changed. If this access specifier is used within list based attributes then the list itself must also be modifiable.
  • The access specifiers {~-} or {-~} (combination of the {-} and {~} access specifiers) indicates that the value it precedes is modifiable and removable.
  • The {+} access specifier can only appear in combination with the keyword UNSPECIFIED or before list attribute values but not within access specifiers preceding list entries. If it appears before list attribute values it can also be combined with the {~} and {-} access specifiers. This access specifier indicates that something can be added to the specification of a job after it has been submitted. For list based attributes it allows that new list entries can be added to the list.

Example: Job Classes - Access Specifiers

Here follows a refinement of the sleeper job class giving its user more flexibility in changing certain aspects of derived jobs:

   jcname          sleeper
   variant_list    NONE
   owner_list      NONE
   user_list       NONE
   xuser_list      NONE
   A               UNSPECIFIED
   a               UNSPECIFIED
   ar              UNSPECIFIED
   b               yes
   binding         UNSPECIFIED
   c_interval      UNSPECIFIED
   c_occasion      UNSPECIFIED
   CMDNAME         /bin/sleep
   CMDARG          60
   ckpt            UNSPECIFIED 
   ac              UNSPECIFIED
   cwd             UNSPECIFIED 
   display         UNSPECIFIED
   dl              UNSPECIFIED
   e               UNSPECIFIED
   h               UNSPECIFIED
   hold_jid        UNSPECIFIED
   i               UNSPECIFIED
   j               UNSPECIFIED
   js              UNSPECIFIED
   l_hard          {~+}{~}a=true,b=true,{-}c=true
   l_soft          {+}UNSPECIFIED
   m               UNSPECIFIED
   M               UNSPECIFIED
   masterq         UNSPECIFIED
   mbind           UNSPECIFIED
   N               {~-}Sleeper
   notify          UNSPECIFIED
   now             UNSPECIFIED
   o               UNSPECIFIED
   P               UNSPECIFIED
   p               UNSPECIFIED
   pe_name         UNSPECIFIED
   q_hard          UNSPECIFIED
   q_soft          UNSPECIFIED
   R               UNSPECIFIED
   r               UNSPECIFIED
   S               /bin/sh
   shell           UNSPECIFIED 
   V               UNSPECIFIED
   v               UNSPECIFIED

Now it is allowed to modify or remove the name of sleeper jobs (N {~-}Sleeper). Users deriving jobs from this class are allowed to add soft resource requests (l_soft {+}UNSPECIFIED). New hard resource requests can be added and the ones which are specified within the job class can be adjusted (l_hard {+~}) but there are additional restrictions: The access specifiers preceding the resource requests (l_hard ...{~}a=true,b=true,{-}c=true) allow the modification of the resource a, the deletion of the resource c whereas the value of resource b is fixed (no access specifier). Users that try to submit or modify jobs that would violate one of the access specifiers will receive an error message and the request is rejected.

Here are some examples for commands that will be successful:

 
  qsub -jc sleeper -N MySleeperName
  qsub -jc sleeper -soft -l new=true
  qsub -jc sleeper -l a=false,b=true,new=true

Here you can see some commands that will be rejected:

  qsub -jc sleeper /path/to/my_own_sleeper 
  qsub -jc sleeper -l a=false,b=false,new=true 
  qsub -jc sleeper -S /bin/tcsh

(1) CMDNAME is not modifiable
(2) l_hard has requested resource b=true. This cannot be changed
(3) S job template attribute does not allow to modify the shell

Different Variants of the same Job Class

Job classes represent an application type in a cluster. If the same application should be started with various different settings or if the possible resource selection applied by the Univa Grid Engine system should depend on the mode how the application should be executed then it is possible to define one job class with multiple variants. So think of it as a way to use the same template for very similar types of jobs, yet with small variations.

The variant_list job class attribute defines the names of all existing job class variants. If the keyword NONE is used or when the list contains only the word default then the job class has only one variant. If multiple names are listed here, separated by commas, then the job class will have multiple variants. The default variant always has to exist. If the variant_list attribute does not contain the word default then it will be automatically added by the Univa Grid Engine system upon creating the job class.

Attribute settings for the additional job class variants are specified similar to the attribute settings of queue instances or queue domains of cluster queues. The setting for a variant attribute has to be preceded by the variant name followed by an equal character ("=") and enclosed in brackets ("[" and "]").

The position where access specifiers have to appear is slightly different in this case. The next example will show this (see the l_soft and N attributes).

Example: Job Classes - Multiple Variants

The following example shows a sleeper job class with three different variants

jcname          sleeper
variant_list    default,short,long
owner_list      NONE
user_list       NONE
xuser_list      NONE
A               UNSPECIFIED
a               UNSPECIFIED
ar              UNSPECIFIED
b               yes 
binding         UNSPECIFIED
c_interval      UNSPECIFIED
c_occasion      UNSPECIFIED
CMDNAME         /bin/sleep
CMDARG          60,[short=5],[long=3600]
ckpt            UNSPECIFIED 
ac              UNSPECIFIED
cwd             UNSPECIFIED 
display         UNSPECIFIED
dl              UNSPECIFIED
e               UNSPECIFIED
h               UNSPECIFIED 
hold_jid        UNSPECIFIED
i               UNSPECIFIED
j               UNSPECIFIED
js              UNSPECIFIED
l_hard          {~+}{~}a=true,b=true,{-}c=true
l_soft          {+}UNSPECIFIED,[{~+}long={~}d=true]
m               UNSPECIFIED
M               UNSPECIFIED
masterq         UNSPECIFIED
mbind           UNSPECIFIED
N               {~-}Sleeper,[{~-}short=ShortSleeper],[long=LongSleeper]
notify          UNSPECIFIED
now             UNSPECIFIED
o               UNSPECIFIED
P               UNSPECIFIED
p               UNSPECIFIED
pe_name         UNSPECIFIED
q_hard          UNSPECIFIED
q_soft          UNSPECIFIED
R               UNSPECIFIED
r               UNSPECIFIED
S               /bin/sh
shell           UNSPECIFIED 
V               UNSPECIFIED
v               UNSPECIFIED

The sleeper job class has now three different variants (variant_list default,short,long). To reference a specific job class variant the name of the job class has to be combined with the name of the variant. Both names have to be separated by a dot ("."). If the variant name is omitted then automatically the default variant is referenced.

qsub -l sleeper
Your job 4099 ("Sleeper") has been submitted

qsub -l sleeper.short
Your job 4100 ("ShortSleeper") has been submitted

qsub -l sleeper.long
Your job 4101 ("LongSleeper") has been submitted

The returned message from the submit commands already indicates that there are differences between the three jobs. The jobs have different names. Compared to the other jobs, the job 4101 has an additional soft resource request d=true (l_soft ...,[{~+}long={~}d=true]). Job 4100 that was derived from the sleeper.short job class variant has no soft requests. Nothing was explicitly specified here for this variant and therefore it will implicitly use the setting of the sleeper.default job class variant (l_soft {+}UNSPECIFIED, … ). Moreover, the job name (see the N attribute) can be modified or removed for the default and short variant but is fixed for the long variant.

Enforcing Cluster Wide Requests with the Template Job Class

After a default installation of Univa Grid Engine 8.1 there exists one job class with the name template. This job class has a special meaning and it cannot be used to create new jobs. Its configuration can only be adjusted by users having the manager role. This jobs class acts as parent job class for all other job classes that are created in the system.

The values of job template attributes in this template job class and the corresponding access specifiers restrict the allowed settings of all corresponding job template attributes of other job classes. As default the {+}UNSPECIFIED add access specifier and keyword is used in the template job class in combination with all job template attributes. Due to that any setting is allowed to other job class attributes after Univa Grid Engine 8.1 has been installed.

This parent-child relationship is especially useful when all jobs that are submitted into a cluster are derived from job classes. Managers might then change the settings within the template. All other existing job classes that violate the settings will then switch into the configuration conflict state. The owners of those job classes have to adjust the settings before new jobs can be derived from them. All those users that intend to create a new job class that violates the settings of the template job class will receive an error.

You will also want to use the template job class to enforce restrictions on the access specifiers which can be used in job classes. Since any job class, whether create by a manager account or by regular users, is derived from the template job class those derived job classes are bound to stay within the limits defined by the template job class. So parameters which have been defined as fixed in the template job class, for instance, cannot be modified in any job class created by a manager or user. Likewise, parameters which have a preset value but are configured to allow deletion only cannot be modified in derived job classes. The Univa Grid Engine Documentations shows the allowed transitions.

blog comments powered by Disqus