Re: [HTCondor-users] Procedure for upgrading between feature releases

["Pelletier, Michael V " <Michael.V.Pelletier@xxxxxxx>]

One of the nice things about HTCondor is that essentially any version can interoperate seamlessly with any other. Any ClassAd attribute that is not recognized by an older version is simply ignored. This makes upgrades very simple no matter how far youâre jumping.

 

In addition, when a running condor_master notices when its own binary has changed, and automatically triggers a restart of itself and the daemons for which itâs responsible.

 

Michael V Pelletier

Principal Technologist

C: +1 339.293.9149
michael.v.pelletier@xxxxxxx

 

From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of Vechinski, Douglas
Sent: Thursday, May 7, 2026 11:03 AM
To: htcondor-users@xxxxxxxxxxx
Subject: [HTCondor-users] Procedure for upgrading between feature releases

 

Iâm trying to find guidance on the process of upgrading a Condor pool. At the moment lets assume upgrading between feature releases of the same major version such as 25.âx.ây -> 25.âx+a.ây+b. The RPMSs are downloaded to a local

Iâm trying to find guidance on the process of upgrading a Condor pool. At the moment lets assume upgrading between feature releases of the same major version such as 25.x.y -> 25.x+a.y+b. The RPMSs are downloaded to a local repository and at some point every couple of months a general update process is applied to the machines for other packages as well (currently using RHEL 8 here). Letâs take 2 cases: A) the condor pool is idle, i.e. no jobs are actively running, B) the condor pool currently has jobs running.

 

Since things are upgraded via RPM packages I assume the executables simply get overwritten. Can condor_master be running on a machine and be upgraded or should it be stopped? Is there any particular order (machine)  that the Condor upgrades should occur? That is should the collector/negotiator be done first before any submit and/or execution machines or does it matter? Can an execute machine that is actively running jobs be updated live. If so, are there potential consequences? The jobs that we typically have running do not have the ability to be checkpointed.

This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.