Re: [Condor-users] STARTD_AD_REEVAL_EXPR message in NegotiatorLog

[Dan Bradley <dan@xxxxxxxxxxxx>]

Steven Timm wrote:

> > I recently discovered this bug too.  There is a fix that will be
> > released with condor 7.0.5 and 7.1.3.
> >
> > The consequence of the bug is that the CurMatches attribute is reset to
> > 0 in some cases before a new update to the site classad is published.
> >
> > --Dan
> >    
> For 3 years Condor staff have been telling us that this was a  feature
> of condor-g matchmaking and that it was supposed to work that way,
> i.e. that CurMatches would reset to zero after every negotiation cycle
> and that it only goes up during the negotiation cycle and will never
> actually show up in the machine classad.  What changed?
>  
I haven't dug into the history of this, but I can tell you how things 
are currently implemented.  ClassAds that have
WantAdRevaluate=True and which define UpdateSequenceNumber as some 
integer may be preserved (at least by the intention of the condor code) 
from one negotiation cycle to the next, effectively ignoring the version 
of the ad that exists in the collector.  The point of this is to 
preserve the value of CurMatches.  The decision about whether to retain 
the negotiator's copy of the ad or not is made by the expression 
specified by the configuration option STARTD_AD_REEVAL_EXPR, which 
defaults to target.UpdateSequenceNumber > my.UpdateSequenceNumber.  
However, the way this expression was being evaluated was wrong, so as 
far as I can see, it never evaluated to true.  In 7.0.5, this is fixed.
I just noticed that STARTD_AD_REEVAL_EXPR is not documented.  I will 
find out if that was intentional.
--Dan