[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [condor-users] Stop Job from matching to the same node

we're working on adding support into the job classad for a list of
hosts where the job ran.  however, until we switch over to the new
version of the ClassAd language (which has native support for lists),
lists are very hard to deal with in "old ClassAds".  so, for now,
you'll have to get by with what i described above.  i hope it helps

Actually, we have this already, though it isn't widely known. It's a bit messy because the released version of Condor is using old ClassAds. Here is some documentation written by a Condor staff member. This is lightly documented in the condor_submit manual page as well. This documentation was written for use with Condor-G matchmaking, but it also works with normal matchmaking.

*** store information in the job classad about N previous matches

In the job submit file you can know state:
   match_list_length = <some integer>

If match_list_length is defined in the job submit description file to
be an integer greater than zero, then the "Name" attribute from the matched
target is stored in the job ad as:

  LastMatchName0 = "some-gatekeeper-ad-name"
  LastMatchName1 = "some-other-gatekeeper-ad-name"

LastMatchName0 will hold the most recent match name. The list will
be rotated (LastMatchName0 will move to LastMatchName1, etc) with a max length
defined by match_list_length in the submit file, which has a default value of zero
(i.e. don't keep this list in the job ad by default). The idea
of this list is to allow the job to prefer to match with a different
resource (or the same) as in the past.

Then make your requirements expression refer to these matches.


Condor Support Information: http://www.cs.wisc.edu/condor/condor-support/ To Unsubscribe, send mail to majordomo@xxxxxxxxxxx with unsubscribe condor-users <your_email_address>