A ClassAd is is a set of uniquely named expressions. Each named expression is called an attribute. Figure 4.1 shows an example of a ClassAd with ten attributes.
ClassAd expressions look very much like expressions in C, and are composed
of literals and attribute references composed with operators. The difference
between ClassAd expressions and C expressions arise from the fact that ClassAd
expressions operate in a much more dynamic environment. For example, an
expression from a machine's ClassAd may refer to an attribute in a job's
ClassAd, such as TARGET.Owner in the above example. The value and type
of the attribute is not known until the expression is evaluated in an
environment which pairs a specific job ClassAd with the machine ClassAd.
ClassAd expressions handle these uncertainties by defining all operators
to be total operators, which means that they have well defined
behavior regardless of supplied operands. This functionality is provided
through two distinguished values, UNDEFINED and ERROR,
and defining all operators so that they can operate on all possible values
in the ClassAd system. For example, the multiplication operator which usually
only operates on numbers, has a well defined behavior if supplied with values
which are not meaningful to multiply. Thus, the expression
10 * "A string" evaluates to the value ERROR. Most operators
are strict with respect to ERROR, which means that they evaluate
to ERROR if any of their operands are ERROR. Similarly,
most operators are strict with respect to UNDEFINED.
[0-9]).
Additionally, the keywords TRUE and FALSE (case
insensitive) are syntactic representations of the integers 1 and 0
respectively.
[0-9]+.[0-9]+).
Attribute names are sequences of alphabetic characters, digits and underscores,
and may not begin with a digit. All characters in the name are significant,
but case is not significant. Thus, Memory, memory and
MeMoRy all refer to the same attribute.
An attribute reference consists of the name of the attribute being referenced, and an optional scope resolution prefix. The three prefixes that may be used are MY., TARGET. and ENV.. The semantics of supplying a prefix are discussed in Section 4.1.2.
=?= and =!=
operators, which are discussed in Section 4.1.2.
*, /, + and - operate
arithmetically only on integers and reals.
==, !=, <=,
<, >= and > operate on integers, reals and strings.
==, !=, <=, < and
>= > are strict with respect to both UNDEFINED
and ERROR.
=?= and =!= behave
similar to == and !=, but are not strict. Semantically,
the =?= tests if its operands are ``identical,'' i.e., have
the same type and the same value. For example, 10 == UNDEFINED
and UNDEFINED == UNDEFINED both evaluate to UNDEFINED,
but 10 =?= UNDEFINED and UNDEFINED =?= UNDEFINED
evaluate to FALSE and TRUE respectively. The
=!= operator test for the ``is not identical to'' condition.
&& and || operate on
integers and reals. The zero value of these types are considered
FALSE and non-zero values TRUE.
UNDEFINED && FALSE evaluates to FALSE, but
UNDEFINED || FALSE evaluates to UNDEFINED.
In both cases, the Requirements expression specifies the correctness criterion that the match must meet, and the Rank expression specifies the desirability of the match (where higher numbers mean better matches). For example, a job ad may contain the following expressions:
Requirements = Arch=="SUN4u" && OpSys == "SOLARIS251" Rank = TARGET.Memory + TARGET.MipsIn this case, the customer requires an UltraSparc computer running the Solaris 2.5.1 operating system. Among all such computers, the customer prefers those with large physical memories and high MIPS ratings. Since the Rank is a user specified metric, any expression may be used to specify the perceived desirability of the match. The condor_negotiator runs algorithms to deliver the ``best'' resource (as defined by the Rank expression) while satisfying other criteria.
Similarly, owners of resources may place constraints and preferences on their machines. For example,
Friend = Owner == "tannenba" || Owner == "wright"
ResearchGroup = Owner == "jbasney" || Owner == "raman"
Trusted = Owner != "rival" && Owner != "riffraff"
Requirements = Trusted && ( ResearchGroup || LoadAvg < 0.3 &&
KeyboardIdle > 15*60 )
Rank = Friend + ResearchGroup*10
The above policy states that the computer will never run jobs owned by
users ``rival'' and ``riffraff,'' while the computer will always run a
job submitted by members of the research group. Furthermore, jobs
submitted by friends are preferred to other foreign jobs, and jobs submitted
by the research group are preferred to jobs submitted by friends.
Note: Because of the dynamic nature of ClassAd expressions, there is no a priori notion of an integer valued expression, a real valued expression, etc. However, it is intuitive to think of the Requirements and Rank expressions as integer valued and real valued expressions respectively. If the actual type of the expression is not of the expected type, the value is assumed to be zero.
For example, to find all computers which have had their keyboards idle for more than 20 minutes and have more than 100 MB of memory:
% condor_status -const 'KeyboardIdle > 20*60 && Memory > 100'
Name Arch OpSys State Activity LoadAv Mem ActvtyTime
amul.cs.wi SUN4u SOLARIS251 Claimed Busy 1.000 128 0+03:45:01
aura.cs.wi SUN4u SOLARIS251 Claimed Busy 1.000 128 0+00:15:01
balder.cs. INTEL SOLARIS251 Claimed Busy 1.000 1024 0+01:05:00
beatrice.c INTEL SOLARIS251 Claimed Busy 1.000 128 0+01:30:02
...
...
Machines Owner Claimed Unclaimed Matched Preempting
SUN4u/SOLARIS251 3 0 3 0 0 0
INTEL/SOLARIS251 21 0 21 0 0 0
SUN4x/SOLARIS251 3 0 3 0 0 0
SGI/IRIX6 1 0 0 1 0 0
INTEL/LINUX 1 0 1 0 0 0
Total 29 0 28 1 0 0
The similar flexibility exists in querying job queues in the Condor system.