Placement: where a pipeline's runs run (orca register --placement), and the control runner, which runs them on the scheduler's own host.
A pipeline's placement is default (stored as null: the scheduler's runner,
ORCA_RUNNER, as before), ec2 (instances of their own, orca.ec2; on a
scheduler whose runner isn't ec2 such runs wait, saying why),
worker:<pool> (a remote worker of that pool starts them, orca.workers,
never the scheduler) or control:
the scheduler starts the run as a child process of its own, the pipeline's
binary with resume <run> as the local runner does, which on AWS is in the
scheduler's container on the control instance (the binary is the project's
image's). Small runs then start in a second, without an instance to boot.
Limits, so a run can't starve Postgres, the scheduler or the UI:
- Memory. Each tick the scheduler adds up the resident memory of each
control-placed run's process tree (
orca.sample.tree_rss) and kills one
over ORCA_CONTROL_MEMORY_MB (1024), failing its attempts with why. Its
processes are also the first the kernel kills if memory runs out before
that (oom_score_adj 1000, on Linux).
- CPU. Its processes run at
nice ORCA_CONTROL_NICE (10), so the
control instance's own processes win when the cores are busy.
- How many. At most
ORCA_CONTROL_MAX_RUNS (2) control-placed runs, of
all pipelines, run at once.
- Pressure. None starts while the control instance's newest minute
(
orca.system, from its sampler) has memory or its fullest disk over 85%.
A run held by either of the last two stays queued with the reason in
runs.held, which its page and JSON show. dista inside such a run is in
local mode, ORCA_CONTROL_WORKERS (1) forked workers.
Secrets (--secret NAME=ID) are read by the scheduler when it starts
the run, with ORCA_SECRET_FETCH as the instances read them, else from
Secrets Manager's API with the scheduler's credentials (the image has no
aws command), and put in the run's environment only, with ORCA_SECRETS
naming them so its logs mask them. Its driver's output is kept in a staging
file and appended to the run's driver.log, masked, by <binary> keep-log
once the process has ended, as on an EC2 head.