Mailing List ArchivesAuthenticated access |
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesAuthenticated access |
|
|
Well..... there is this not-so-well-documented feature of doing some
magic to the classads, which might be of use to you. It’s the concept of classad-shared-libraries, where you can
define custom functions that can be used as classad expressions. Example:- Machine Ad:- Memory = 1024 Arch = “INTEL” OpSys = “LINUX” Job Ad:- Requirements = Arch == “INTEL” && OpSys ==
“LINUX” && memoryIsGreaterThan(1000) Now the function memoryIsGreaterThan() is written in C, which would include
the header file “classad_shared.h” & linked as... $ gcc -fPIC -shared -o libshared.so shared.C The condor config file should contain this config value... CLASSAD_LIB_PATH = /path/to/libshared.so Along these lines, you could write your own function
‘versionIs()’, which would essentially do a substring-check so you
could write... Requirements = versionIs(target.CondorVersion,”6.7”) I’ve attached the header file “classad_shared.h”
& the file with example shared-library-classad functions. I suspect this is not a widely used feature (going by the fact that,
there is no trace of documentation) because there would be calls to dlopen() to
load this shared library each time this function is encountered in a classad,
making it a not-so-efficient operation. Another, huge issue would be security, as the code in the shared source
segment could be potentially malicious and this would effectively be linked
with a condor-daemon with root-level privileges Lemme know, if you have more questions about using this feature. Regards, Swaroop Sayeram Member of Technical Staff Direct : +1.408.321.9000 Ext:227 Fax : +1.408.321.9030 swaroop@xxxxxxxxxx Optena Corporation www.optena.com This electronic transmission (and any attached documents) contains information
from Optena Corporation and is for the sole use of the individual or entity it
is addressed to. If you receive this message in error, please notify me and
destroy the attached message (and all attached documents) immediately. -----Original Message----- > > The machines are still locking
when Condor hits a bad machine > running > > 6.6.9 > > Is there a way I can tell jobs to only run
on the 6.6.10 machines? > > I have searched the manual and the previous
posts and have not found > > anything. > > Anything that appears in the ClassAd of a startd
can be used in the > requirements _expression_ in your submission
ticket. So: > > requirements = CondorVersion ==
"$CondorVersion: 6.6.10 Apr 27 2005 $" > > NB: I faked that example -- I have 6.7.x running
here so the exact > string you should use to match only 6.6.10
machines needs to be > determined at your site. Actually, this got me thinking that a better way to
match versions would be if the version information was separated out into
major, minor and minor-minor attributes like this: CondorVersionMajor = 6 CondorVersionMinor = 7 CondorVersionMinorMinor
= 7 Then I could say, "Run on all 6.7.x
machines" with: requirements = condorversionmajor == 6 &&
condorversionminor == 7 Or, "Run on only machines with 6.7.5 or
higher" with: requirements = condorversionmajor == 6 &&
condorversionminor == 7 && condorversionminorminor >= 5 Which is a level of version control not capable with
the string format currently used to indicate the version of condor
running on a machine via it's ClassAd. Consider this my feature request to have these
attributes defined automagically on the startd. - Ian |
Attachment:
classad_shared.h
Description: classad_shared.h
Attachment:
shared.C
Description: shared.C