ClassAds are a flexible mechanism for representing the characteristics and constraints of machines and jobs in the Condor system. ClassAds are used extensively in the Condor system to represent jobs, resources, submitters and other Condor daemons. An understanding of this mechanism is required to harness the full flexibility of the Condor system.
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
and functions.
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.
ClassAds have existed for quite some time in two forms: Old and New. Old ClassAds were the original form and were used in Condor until Condor version 7.5.0. They were heavily tied to the Condor development libraries. New ClassAds added new features and were designed as a stand-alone library that could be used apart from Condor.
In Condor version 7.5.1, Condor switched the internal usage of ClassAds from Old to New. All user interaction with tools (such as condor_q) as well as output of tools is still done as Old ClassAds. Before Condor version 7.5.1, New ClassAds were used in just a few places within Condor, for example, in the Job Router and in condor_q -better-analyze. There are some syntax and behavior differences between Old and New ClassAds, all of which will remain invisible to users of Condor for this version. A complete description of New ClassAds can be found at http://www.cs.wisc.edu/condor/classad/, and in the ClassAd Language Reference Manual found on this web page.
Some of the features of New ClassAds that are not in Old ClassAds are lists, nested ads, time values, and matching groups of ads. Condor will avoid using these features until the 7.7.x development series, as using them makes it difficult to interact with older versions of Condor.
The syntax varies slightly between Old and New ClassAds. Here is an example ClassAd presented in both forms. The Old form:
Foo = 3 Bar = "ab\"cd\ef" Moo = Foo =!= Undefined
The New form:
[ Foo = 3; Bar = "ab\"cd\\ef"; Moo = Foo isnt Undefined; ]
Condor will convert to and from Old ClassAd syntax as needed.
Expressions often refer to ClassAd attributes. These attribute references work differently in Old ClassAds as compared with New ClassAds. In New ClassAds, an unscoped reference is looked for only in the local ClassAd. An unscoped reference is an attribute that does not have a MY. or TARGET. prefix. The local ClassAd may be described by an example. Matchmaking uses two ClassAds: the job ClassAd and the machine ClassAd. The job ClassAd is evaluated to see if it is a match for the machine ClassAd. The job ClassAd is the local ClassAd. Therefore, in the Requirements attribute of the job ClassAd, any attribute without the prefix TARGET. is looked up only in the job ClassAd. With New ClassAd evaluation, the use of the prefix MY. is eliminated, as an unscoped reference can only refer to the local ClassAd.
The MY. and TARGET. scoping prefixes only apply when evaluating an expression within the context of two ClassAds. Two examples that exemplify this are matchmaking and machine policy evaluation. When evaluating an expression within the context of a single ClassAd, MY. and TARGET. are not defined. Using them within the context of a single ClassAd will result in a value of Undefined. Two examples that exemplify evaluating an expression within the context of a single ClassAd are during user job policy evaluation, and with the -constraint option to command-line tools.
New ClassAds have no CurrentTime attribute. If needed, use the time() function instead. In order to mimic Old ClassAd semantics in this Condor version 7.5.1 release, all ClassAds have an explicit CurrentTime attribute, with a value of time().
In this Condor version 7.5.1 release, New ClassAds will mimic the evaluation behavior of Old ClassAds. No configuration variables or submit description file contents should need to be changed. To eliminate this behavior and use only the semantics of New ClassAds, set the configuration variable STRICT_CLASSAD_EVALUATION to True. This permits testing expressions to see if any adjustment is required, before a future version of Condor potentially makes New ClassAds evaluation behavior the default or the only option.
[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 prefixes that may be used are MY. and TARGET.. The case used for these prefixes is not significant. The semantics of supplying a prefix are discussed in Section 4.1.3.
=?= and =!=
operators, which are discussed in Section 4.1.3.
Here are descriptions of each of these predefined functions.
The possible types are the same as itemized in
in Section 4.1.2.
Where the type may be any of these literal types, it is
called out as AnyType.
Where the type is Integer, but only returns
the value 1 or 0 (implying True or False),
it is called out as Boolean.
The format of each function is given as
ReturnType FunctionName(ParameterType parameter1, ParameterType parameter2, ...)Optional parameters are given within square brackets.
"slot15_State", and this string is then evaluated.
Note that referring to attributes of a job from within the string passed to eval() in the Requirements or Rank expressions could cause inaccuracies in Condor's automatic auto-clustering of jobs into equivalent groups for matchmaking purposes. This is because Condor needs to determine which ClassAd attributes are significant for matchmaking purposes, and indirect references from within the string passed to eval() will not be counted.
This function returns ERROR if other than exactly 3 arguments are given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if greater than 1 argument is given.
This function returns ERROR if greater than 3 or less than 2 arguments are given.
This function returns ERROR if other than 2 arguments are given.
This function returns ERROR if greater than 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
This function returns ERROR if other than exactly 1 argument is given.
Returns a formatted string that is a representation of time. The argument time is interpreted as coordinated universe time in seconds, since midnight of January 1, 1970. If not specified, time will default to the value of attribute CurrentTime.
The argument format is interpreted similarly to the format argument of the ANSI C strftime function. It consists of arbitrary text plus placeholders for elements of the time. These placeholders are percent signs (%) followed by a single letter. To have a percent sign in the output, use a double percent sign (%%). If format is not specified, it defaults to %c.
Because the implementation uses strftime() to implement this,
and some
versions implement extra, non-ANSI C options, the exact options
available to an implementation may vary. An implementation is only
required to implement the ANSI C options, which are:
For the following functions, a delimiter is represented by a string. Each character within the delimiter string delimits individual strings within a list of strings that is given by a single string. The default delimiter contains the comma and space characters. A string within the list is ended (delimited) by one or more characters within the delimiter string.
This function returns ERROR if other than 1 or 2 arguments are given.
The following three functions utilize regular expressions as defined and supported by the PCRE library. See http://www.pcre.org for complete documentation of regular expressions.
The options argument to these functions is a string of special characters that modify the use of the regular expressions. Inclusion of characters other than these as options are ignored.
^) and dollar sign
($) characters.
The carat character matches the start of a string, as well as
after each newline character.
The dollar sign character matches before a newline character.
4.1.3.1 Literals
Literals are self-evaluating, Thus, integer, string, real, undefined and
error values evaluate to themselves.
Since the expression evaluation is being carried out in the context of two
ClassAds, there is a potential for name space ambiguities. The following
rules define the semantics of attribute references made by ad
4.1.3.2 Attribute References
that is being
evaluated in a context with another ad
:
. If the named attribute does not exist in
, the
value of the reference is UNDEFINED. Otherwise, the
value of the reference is the value of the expression bound to
the attribute name.
. If the named attribute does not exist in
, the value of the reference is UNDEFINED. Otherwise,
the value of the reference is the value of the expression bound to
the attribute name.
, the value of the reference
is the value of the expression bound to the attribute name in
.
, the value of the
reference is the value of the expression bound to the attribute
name in
.
All operators in the ClassAd language are total, and thus have well
defined behavior regardless of the supplied operands. Furthermore, most
operators are strict with respect to ERROR and
UNDEFINED, and thus evaluate to ERROR or UNDEFINED
if either of their operands have these exceptional values.
4.1.3.3 Operators
*, /, + and - operate
arithmetically only on integers and reals.
==, !=, <=,
<, >= and > operate on integers, reals and strings.
=?= and =!=, which do case sensitive
comparisons assuming both sides are 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.
TRUE && "foobar" evaluates to ERROR.
The =?= operator is similar to the == operator. It checks if the left hand side operand is identical in both type and value to the the right hand side operand, returning TRUE when they are identical. A key point in understanding is that the =?= operator only produces evaluation results of TRUE and FALSE, where the == operator may produce evaluation results TRUE, FALSE, UNDEFINED, or ERROR. Table 4.1 presents examples that define the outcome of the == operator. Table 4.2 presents examples that define the outcome of the =?= operator.
|
|
The =!= operator is similar to the != operator. It checks if the left hand side operand is not identical in both type and value to the the right hand side operand, returning FALSE when they are identical. A key point in understanding is that the =!= operator only produces evaluation results of TRUE and FALSE, where the != operator may produce evaluation results TRUE, FALSE, UNDEFINED, or ERROR. Table 4.3 presents examples that define the outcome of the != operator. Table 4.4 presents examples that define the outcome of the =!= operator.
|
|
4.1.4 Old ClassAds in the Condor System
The simplicity and flexibility of ClassAds is heavily exploited in the Condor
system. ClassAds are not only used to represent machines and jobs in the
Condor pool, but also other entities that exist in the pool such as
checkpoint servers, submitters of jobs and master daemons. Since arbitrary
expressions may be supplied and evaluated over these ads, users have a uniform
and powerful mechanism to specify constraints over these ads. These constraints
can take the form of Requirements expressions in resource and job ads,
or queries over other ads.
The requirements and rank expressions
within the submit description file
are the mechanism
by which users specify the constraints and preferences of jobs.
For machines, the configuration determines both
constraints and preferences of the machines.
4.1.4.1 Constraints and Preferences
For both machine and job, 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 job 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 daemon runs algorithms to deliver the best resource (as defined by the rank expression) while satisfying other required criteria.
Similarly, the machine may place constraints and preferences on the jobs that it will run by setting the machine's configuration. For example,
Friend = Owner == "tannenba" || Owner == "wright"
ResearchGroup = Owner == "jbasney" || Owner == "raman"
Trusted = Owner != "rival" && Owner != "riffraff"
START = 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.
Needed syntax is different on Unix and Windows platforms, due to the interpretation of characters in forming command-line arguments. The expression must be a single command-line argument, and the resulting examples differ for the platforms. For Unix shells, single quote marks are used to delimit a single argument. For a Windows command window, double quote marks are used to delimit a single argument. Within the argument, Unix escapes the double quote mark by prepending a backslash to the double quote mark. Windows escapes the double quote mark by prepending another double quote mark. There may not be spaces in between.
Here are several examples. To find all computers which have had their keyboards idle for more than 20 minutes and have more than 100 MB of memory, the desired ClassAd expression is
KeyboardIdle > 20*60 && Memory > 100On a Unix platform, the command appears as
% 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
INTEL/WINNT51 1 0 0 1 0 0
INTEL/LINUX 1 0 1 0 0 0
Total 29 0 28 1 0 0
The Windows equivalent command is
>condor_status -const "KeyboardIdle > 20*60 && Memory > 100"
Here is an example for a Unix platform that utilizes a regular expression ClassAd function to list specific information. A file contains ClassAd information. condor_advertise is used to inject this information, and condor_status constrains the search with an expression that contains a ClassAd function.
% cat ad
MyType = "Generic"
FauxType = "DBMS"
Name = "random-test"
Machine = "f05.cs.wisc.edu"
MyAddress = "<128.105.149.105:34000>"
DaemonStartTime = 1153192799
UpdateSequenceNumber = 1
% condor_advertise UPDATE_AD_GENERIC ad
% condor_status -any -constraint 'FauxType=="DBMS" && regexp("random.*", Name, "i")'
MyType TargetType Name
Generic None random-test
The ClassAd expression describing a machine that advertises a Windows NT operating system:
OpSys == "WINNT51"Here are three equivalent ways on a Unix platform to list all machines advertising a Windows NT operating system. Spaces appear in these examples to show where they are permitted.
% condor_status -constraint ' OpSys == "WINNT51" '
% condor_status -constraint OpSys==\"WINNT51\"
% condor_status -constraint "OpSys==\"WINNT51\""
The equivalent command on a Windows platform to list all machines advertising a Windows NT operating system must delimit the single argument with double quote marks, and then escape the needed double quote marks that identify the string within the expression. Spaces appear in this example where they are permitted.
>condor_status -constraint " OpSys == ""WINNT51"" "condor-admin@cs.wisc.edu