Re: [HTCondor-users] ep custom configuration

[Antonio Falabella <antonio.falabella@xxxxxxx>]

Dear Steffen,

Is there docs for the STARD_CRON? could you point me to that?

What's your thoughts about the condor_kbdd-like thing?

Thanks

Antonio

On 25/04/25 14:40, Steffen Grunewald wrote:
> Hi Antonio,
>
> On Fri, 2025-04-25 at 13:55:55 +0200, HTCondor Users Mailinglist wrote:
> > Dear developers,
> >
> > I looking for a specific configuration of the execution points of a cluster
> > that I am configuring. The use case is the following: we have big cluster
> > for data acquisition that must allow the execution of jobs through condor
> > only when it is idle, that is when data acquisition is not running. When the
> > data acquisition starts the worker nodes must not run any new jobs. This
> > should be dynamic and looking in the documentation here:
> >
> > https://htcondor.readthedocs.io/en/latest/admin-manual/ep-policy-configuration.html
> >
> > in particular the "START Expression" this is something very similar to the
> > behavior that can be obtained with "KeyboardIdle" machine classad. Now the
> > question comes, is it possible to have a a custom machine classad like the
> > keyboard one that say, given the status of the machine it enables or
> > disables the job submission? The state of the machine exposed through the
> > machine classad should be custom i.e. if some particular process starts on
> > the machine or some other condition happens then I can set
> >
> > a START expression like
> >
> > START = NewCustomClassAd > 15 * $(MINUTE)
> >
> > To me it looks like I can mimic the structure of condor_kbdd and create a
> > custom daemon that exposes the before mentioned custom machine classad. But
> > I am here to ask you if there is something easier to accomplish this.
> At first glance, a STARTD_CRON job/hook (run periodically, detecting the running
> task and setting an attribute accordingly) might do what you're looking for?
> You may want to keep in mind that it'll take a while for the ClassAd to migrate
> and be used for matching _new_ jobs; also the START expression won't affect any
> jobs that are _already running_...
>
> Best,
>   Steffen