Re: [HTCondor-users] Understanding "How to have execute machines belong to multiple pools" configuration

[John M Knoeller <johnkn@xxxxxxxxxxx>]

The basic strategy would still work, big change between now and when this how-to was written is that HTCondor now no longer does security config based only on hostnames,  so any config knob that starts with ALLOW_ will need to have valid security identifiers and not just hostnames. 

The SUPER_START recipe is using a very old mechanism that won't work for users that submit to or AP remotely.   I would suggest that you delete everything from 

CurJobPool = "$$(NegotiatorMatchExprNegotiatorName)"

to the end of the example configuration.   

If you want  something like SUPER_START.  there are more reliable mechanism available now such as JOB_TRANSFORM_NAMES in the AP.

-tj

---

From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of Nikita Balashov via HTCondor-users <htcondor-users@xxxxxxxxxxx>
Sent: Wednesday, June 26, 2024 8:08 AM
To: htcondor-users@xxxxxxxxxxx <htcondor-users@xxxxxxxxxxx>
Cc: Nikita Balashov <balashov@xxxxxxx>
Subject: [HTCondor-users] Understanding "How to have execute machines belong to multiple pools" configuration

 

Hi,

I'm seeking advice from experts regarding the configuration described here. It seems to be perfectly matching my use case: 

We have three pools, two of which are owned by two different departments and one that is shared by everyone. The two departments don't mind sharing their resources when they are idle, but they also want to have absolute priority for their own users' jobs in their pools. So according to the proposed configuration, the "shared" pool could be made into a super-pool, with other pools' WNs reporting to their own CMs and the super pool. In this setup users would submit jobs to their own pools flocking them to the super-pool. Is the referenced configuration example still applicable in HTCondor 23 and aligns with my use case?

Thanks,

Nikita Balashov