<commit_before>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\label{sec:job-hooks}Job Hooks}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Job hooks|(}

\index{Job hooks!introduction} 
A \Term{hook} is an external program or script invoked by Condor at various
points during the life cycle of a job.
Instead of putting all the code and logic directly into the Condor
daemons to handle the variety of external systems from which it
might fetch work,
sites can write their own programs or scripts and allow
Condor to invoke these hooks at the right moments to accomplish the
desired outcome.
This eliminates the expense of the matchmaking and 
scheduling provided by the the \Condor{schedd} and
the \Condor{negotiator}, although at the price of the flexibility
they offer.
Therefore, the hooks allow Condor to more easily and directly interface with
external scheduling systems.


The following sections describe the system of hooks,
both for work that is fetched from an external system,
and for hooks that behave as a Job Router.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{\label{sec:job-hooks-overview}
Hooks that Fetch Work}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Job hooks!overview} 

In the past, Condor has always sent work to the execute machines by
pushing jobs to the \Condor{startd} daemon, either from the \Condor{schedd}
daemon or via \Condor{cod}.
Beginning with the Condor 7.1.0, the \Condor{startd} daemon now has the
ability to pull work by fetching jobs via a system of plug-ins or
hooks.
Any site can configure a set of hooks to fetch work completely
outside of the usual Condor matchmaking system.

A projected use of the hook mechanism implements what might
be termed a \Term{glide-in factory}, especially where the
factory is behind a firewall.
Without using the hook mechanism to fetch work,
a glide-in \Condor{startd} daemon behind a firewall
depends on GCB to help it listen and eventually receive
work pushed from elsewhere.
With the hook mechanism, a glide-in \Condor{startd} daemon
behind a firewall uses the hook to pull work.
The hook needs only an outbound network connection to complete
its task,
thereby being able to operate from behind the firewall,
without the intervention of GCB.

Periodically, each execution slot managed by a \Condor{startd} will
invoke a hook to see if there is any work that can be fetched.
Whenever this hook returns a valid job, the \Condor{startd} will
evaluate the current state of the slot and decide if it should start
executing the fetched work.<commit_msg>Changed GCB reference to CCB in order to keep with the times.<commit_after>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\label{sec:job-hooks}Job Hooks}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Job hooks|(}

\index{Job hooks!introduction} 
A \Term{hook} is an external program or script invoked by Condor at various
points during the life cycle of a job.
Instead of putting all the code and logic directly into the Condor
daemons to handle the variety of external systems from which it
might fetch work,
sites can write their own programs or scripts and allow
Condor to invoke these hooks at the right moments to accomplish the
desired outcome.
This eliminates the expense of the matchmaking and 
scheduling provided by the the \Condor{schedd} and
the \Condor{negotiator}, although at the price of the flexibility
they offer.
Therefore, the hooks allow Condor to more easily and directly interface with
external scheduling systems.


The following sections describe the system of hooks,
both for work that is fetched from an external system,
and for hooks that behave as a Job Router.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{\label{sec:job-hooks-overview}
Hooks that Fetch Work}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Job hooks!overview} 

In the past, Condor has always sent work to the execute machines by
pushing jobs to the \Condor{startd} daemon, either from the \Condor{schedd}
daemon or via \Condor{cod}.
Beginning with the Condor 7.1.0, the \Condor{startd} daemon now has the
ability to pull work by fetching jobs via a system of plug-ins or
hooks.
Any site can configure a set of hooks to fetch work completely
outside of the usual Condor matchmaking system.

A projected use of the hook mechanism implements what might
be termed a \Term{glide-in factory}, especially where the
factory is behind a firewall.
Without using the hook mechanism to fetch work,
a glide-in \Condor{startd} daemon behind a firewall
depends on CCB to help it listen and eventually receive
work pushed from elsewhere.
With the hook mechanism, a glide-in \Condor{startd} daemon
behind a firewall uses the hook to pull work.
The hook needs only an outbound network connection to complete
its task,
thereby being able to operate from behind the firewall,
without the intervention of CCB.

Periodically, each execution slot managed by a \Condor{startd} will
invoke a hook to see if there is any work that can be fetched.
Whenever this hook returns a valid job, the \Condor{startd} will
evaluate the current state of the slot and decide if it should start
executing the fetched work.
{'fraction_non_alphanumeric': 0.14283060921248142, 'fraction_numerical': 0.001114413075780089, 'mean_word_length': 5.2543554006968645, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6777166', 'n_tokens_mistral': 1387, 'n_tokens_neox': 1312, 'n_words': 748}