Qube!'s requirement specification is expression based. The proper use of these expressions will allow a user to specify the host and/or the conditions required before a job is allowed to run.
The syntax for specifying the expression is similar to Perl or C. The evaluation of the expression where:
<expression> == true
allows the job to be dispatched to a qualifying host. An expression consists of operators and operands. Operators are either text or symbolic.
These are equivalent:
eq, ==, =
String and numeric comparisons are automatically resolved based upon the values they resolve to.
Since a job requirement can include a number of operator characters, any reference to a property or resource that includes an operator should be quoted so the interpreter can differentiate between the literal character and the operator.
qbsub --requirements "host.kernel_version eq '2.6.17-1.2142_FC4smp'"
10 min 12
10 max 12
10 sub 8
1 + 2
3 * 4
14 / 7
12 xor 8
10 % 4
value in list (string with commas)
"v" in "x,y,v"
list (string with commas) has value
"x,y,v" has "v"
eq, =, ==
10 == 10
ne, <>, !=
10 != 10
1 and 0
|or, ||||OR||1 or 0||true|
12 & 8
||||bitwise OR||8 | 4||12|
5 < 10
5 > 10
less than or equal
4 >= 6
greater than or equal
4 <= 6
bitwise right shift (used to divide by 2n)
4 >> 1
bitwise left shift (used to multiply by 2n)
4 << 1
The reason for multiple definitions for most operators is to allow a programmer more flexibility in the case of Unix command line applications where reserved characters like the ">", unless otherwise escaped, will be interpreted by the shell.
Operands in Qube! also have a syntax. They all follow a base
"linux", "irix", "winnt", "osx"
CPU speed in MHz
Version reported by the operating system.
Comma delimited list of group names
Cluster specification string
List of restricted cluster specification strings
Numeric representation of the Worker's flags
Worker version of Qube!
Comma delimited list of job types
true if the flag exists
Comma delimited list of job properties for jobs on the worker.
Here are some examples of job requirements that include property expressions:
% qbsub --requirements "host.os eq linux" ls
% qbsub --requirements "host.name eq host01" ls
% qbsub --requirements "host.flag.remove_logs host.group has host05" ls
% qbsub --requirements "(host.os == 'winnt') and host.processor_speed >= 100" ls
are slightly different and include those defined by your administrator host.
host.processors.[ used | avail | total ]
Number of processors available on the worker
host.memory.[ used | avail | total ]
Memory in Mb available on the worker
host.swap.[ used | avail | total ]
Swap space available in Mb on the worker
Here is an example of a job requirement that uses a host resource expression:
% qbsub --requirements "host.processors.total > 10" ls
The possible operands for a job.type are:
job's parent id
job process group
job's cluster value
user defined job "kind"
job's flags numeric value
true if the flag exists
Here are examples of job requirements that use job resource expressions:
% qbsub --requirements "job.type in host.jobtypes" ls% qbsub --requirements "job.user eq host.name" ls
Advanced Requirements Expression Examples
More advanced uses of the requirements expression allow Qube! users to route a job to a specific host and also conversely restrict a job from a host.
Run my job only on linux hosts:
host.os eq linux
Run my job on any host except qb001:
host.name ne "qb001"
Run the job on a host with the Maya job type:
"maya" in host.jobtypes
Run my job only on dual processor hosts:
host.processors.total == 2
Run my job only if there isn't already one of this job's instances running on it:
not (job.id in host.duty.id)
Run only one "kind" of job on a worker at the same time (this will allow other kinds of jobs still to run, different from reserving all job slots)
job.kind = 'test' (or any other value, your choice...)
not(job.kind in host.duty.kind)