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

[John M Knoeller <johnkn@xxxxxxxxxxx>]

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)