Re: [HTCondor-users] CondorCE: handling of requirements ad/macro in (pre)routes

[Thomas Hartmann <thomas.hartmann@xxxxxxx>]

Hi TJ,

many thanks for the hint - with My.attribute everything looks as I have 
wished for :D

The double NODE_IS_HEALTHY is just an artefact from me fiddling around - 
I wanted to see if it might be somehow dependent on the order (maybe 
evaluation left -> right vs right -> left or so)

You helped me on the right track - our routes should become much nicer 
looking now ;)

Cheers and many thanks,
 Thomas

On 20/03/2025 16.04, John M Knoeller via HTCondor-users wrote:
> in CE Routes and transforms, to refer to attributes of the job in a $() 
> substitution, you need to use $(MY.attribute).
> So if you want a route statement to expand the job requrements, use 
> $(MY.Requirements).
> Use of $(requirements)Â without the MY. prefix will refer to the route 
> temp variable requirements, which will usually be empty.
>
> So your route statement would be something like
>
>  Â ÂSET Requirements = NODE_IS_HEALTHY && $(My.Requirements) && 
> NODE_IS_HEALTHY
>
> Did you intend to add NODE_IS_HEALTHY twice here?
>
> Note that the statement with out MY. will probably not parse as a valid 
> classad expression, you end up trying to parse something like this.
>
>  Â ÂSET Requirements = NODE_IS_HEALTHY && Â&& NODE_IS_HEALTHY
>
> But the && &&Â in the middle there will not parse.
>
> -tj
>
> ------------------------------------------------------------------------
> *From:*ÂHTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of 
> Thomas Hartmann <thomas.hartmann@xxxxxxx>
> *Sent:*ÂWednesday, March 19, 2025 6:44 AM
> *To:*Âcondor-users@xxxxxxxxxxx <condor-users@xxxxxxxxxxx>
> *Subject:*Â[HTCondor-users] CondorCE: handling of requirements ad/macro 
> in (pre)routes
> Hi all,
>
> I am currently rewriting our (pre)routes and noticed some odd behaviour
> regarding how requirements is handled.
>
> My plan was to set a new REQUIREMENT that includes the default
> requirements **and** a new condition. However, SET (or EVAL) seem to
> treat the evaluation of $(requirements) differently than other ads/macros.
>
> E.g., I would like to require a "NODE_IS_HEALTHY" ad as condition in a
> (pre)route that is set by a cron/test - in addition to the requirements
> that already exists until this (pre)route.
>
> Setting in the PRE_ROUTE (SET/EVALSET)
>  ÂÂ SET REQUIREMENTS = NODE_IS_HEALTHY && $(requirements) && NODE_IS_HEALTHY
>
> results in the routed job in Condor in a condition
>
>  ÂÂ Requirements = true && TARGET.OPSYS == "LINUX" && TARGET.ARCH ==
> "X86_64" && TARGET.HasFileTransfer && TARGET.Disk >= RequestDisk &&
> TARGET.Memory >= RequestMemory && TARGET.Cpus >= RequestCpus
>
> ---
>
> Apparently both occurrences of "NODE_IS_HEALTHY" got dropped and with
>
>  ÂÂÂ SET REQUIREMENTS = $(requirements)
>
> in the preroute, the resulting job's requirements condition is evaluated to
>
>  ÂÂ Requirements = true && TARGET.OPSYS == "LINUX" && TARGET.ARCH ==
> "X86_64" && TARGET.HasFileTransfer && TARGET.Disk >= RequestDisk &&
> TARGET.Memory >= RequestMemory && TARGET.Cpus >= RequestCpus
>
> as well (note the initial true in the condition)
>
> ---
>
> Also going via a temporary ad did not change the behaviour and
>
>  Â COPY requirements REQUIREMENTSTMP
>  Â SET REQUIREMENTS = NODE_IS_HEALTHY && $(REQUIREMENTSTMP)
>
> ended up in
>
>  ÂÂ Requirements = true && TARGET.OPSYS == "LINUX" && TARGET.ARCH ==
> "X86_64" && TARGET.HasFileTransfer && TARGET.Disk >= RequestDisk &&
> TARGET.Memory >= RequestMemory && TARGET.Cpus >= RequestCpus
>  ÂÂ REQUIREMENTSTMP = true && TARGET.OPSYS == "LINUX" && TARGET.ARCH ==
> "X86_64" && TARGET.HasFileTransfer && TARGET.Disk >= RequestDisk &&
> TARGET.Memory >= RequestMemory && TARGET.Cpus >= RequestCpus
>
> ---
>
> Similarly, when trying to set some throwaway ads, the resulting ads are
> heavily coupled to the requirements. E.g., when setting in the preroute
> some toy expression like
>
>  Â SET FOOTEST = NODE_IS_HEALTHY && 2048 && $(requirements)
>  Â SET FOOTEST2 = NODE_IS_HEALTHY && 2048
>
> in the resulting LRMS job
>  ÂÂ FOOTEST is undefined
> but
>  ÂÂ FOOTEST2 = NODE_IS_HEALTHY && 2048
>
> which is a bit confusing to me (would have expected that with a plain
> SET the requirements would not be evaluated(?) in place, or?
>
> AFAIS requirements.upper/lower is somewhat reserved and needs to be
> treated with care, or?
> Maybe I got the flow somewhat wrong?
>
> And coming back to my initial problem but what would be the suggested
> way to merge existing requirements with additional ones in a (pre)route
> into an extended requirements expression? All ideas are appreciated ;)
>
> Installed packages are as [1]
>
> Cheers,
>  ÂÂ Thomas
>
>
> [1]
> condor-24.3.0-1.el9.x86_64
> condor-placeholder-0.0.0-0.el9.noarch
> condor-upgrade-checks-23.10.20-1.el9.x86_64
> htcondor-ce-24.0.2-1.el9.noarch
> htcondor-ce-bdii-24.0.2-1.el9.noarch
> htcondor-ce-client-24.0.2-1.el9.noarch
> htcondor-ce-condor-24.0.2-1.el9.noarch
> python3-condor-24.3.0-1.el9.x86_64
>
>
> [ps]
> out of curiosity I tried also a preroute run with
>  Â SET REQUIREMENTS = requirements
>
> which naturally resulted in an idle job not finding a matching EP
>
> interestingly, I could segfault my sched with a better-analyze attempt ð
>
>  Â> condor_q -better-analyze 31
>
>
> -- Schedd: grid-htc-preprod-ce01.desy.de : <131.169.223.128:3185?...
> Segmentation fault (core dumped)
>
>
>
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
>
> Join us in June at Throughput Computing 25: https://osg-htc.org/htc25
>
> The archives can be found at: https://www-auth.cs.wisc.edu/lists/htcondor-users/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature