Re: [HTCondor-users] Multiple CredDs in a single pool

[John M Knoeller <johnkn@xxxxxxxxxxx>]

Hi Miguel. 

 

You can have multiple CREDD daemons running, but HTCondor is not really expecting them to be setup as backups for each other.  The purpose of the CredD classad is to allow the daemons to find the address of a CREDD given the name.  I think I you are saying that both of the CREDD daemons are advertising the same IP address?

 

In that case I think you can configure credd host to be the IP address and port of the credd rather than setting it to a name.

 

CREDD_HOST=a.b.c.d:port

 

I canât say for certain that this will work, but I think it will work if you make sure that both of the CREDDs have the same address and all of the same credentials stored.

 

The other issue is that condor_submit will automatically add a clause to the job Requirements _expression_ so that jobs that want to run_as_owner will only match to machines that advertise a value for LocalCredd that is the same as the CREDD_HOST of condor_submit.

 

The job will have something like

 && (TARGET.LocalCredd =?= "$(CREDD_HOST)")

 

where $(CREDD_HOST) is the value from the configuration.  This is only used for matchmaking, so it wonât matter what the value actually is, only that itâs the same string on both the submit machines and the execute machines.

 

As for pool password being required for the credd daemon, I do think that having them both use the same signing key name and key value will work just fine.

 

Hope this helps,

-tj

 

 

From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of Miguel Garrido
Sent: Monday, December 19, 2022 3:53 PM
To: htcondor-users@xxxxxxxxxxx
Subject: [HTCondor-users] Multiple CredDs in a single pool

 

Hi

 

I am currently managing a pool that has two credd systems behind a virtual IP and every node in the pool's config is currently defining `CREDD_HOST` pointing to the DNS name of the virtual IP. With this setup, running `condor_status -subsystem credd` yields a single CredD ClassAd - belonging to the daemon on the system that started most recently. The idea behind the virtual IP was high availability of the CredD daemon, however since only one CredD class ad exists, I am not certain it is doing the right thing.

 

I've tested having two separate systems advertise themselves as CredD daemons without defining `CREDD_HOST` across the pool. This configuration results in having two CredD class ads in the pool (one for each configured system) but there is subsequently no LocalCredd attribute being defined on the execute nodes; I think because we are omitting `CREDD_HOST`.

 

Are multiple CredD hosts supported in a single pool, and if so, how can we help the execute nodes pick one as the LocalCredd? I am only worried about the existence of a LocalCredd being chosen because the documentation states that this is necessary to run jobs as the owner on Windows.

 

While I am mentioning the documentation, I also noticed the documentation calling out a shared pool password as a prerequisite for the credd_daemon. Am I correct to assume that a shared signing key when using IDTOKEN authentication can stand in for the shared pool password?

 

Thank you