JobRequirements

Resource and policy requirements for a single job. See §3.5.

Field

Type

Repeated

Description

required_capacity

double

vCPUs (fractional) — the same scale nodes advertise as NodeInventory.total_capacity.

required_cores

OptionalInt

Omit to share whatever cores are available.

required_gpu_capacity

OptionalFloat

Omit if the job doesn’t need a GPU.

required_gpu_model

OptionalString

required_capabilities

CapabilityRequirement

on_runtime_failure

OnRuntimeFailure

required_host_ports

string

Fixed host sockets the job binds on its node, as canonical PORT/proto tokens (e.g. "5001/udp"). Exclusive per node: placement refuses a node where another job already claimed one. Declared ports only — the node-side bind failure stays authoritative for anything undeclared.

max_restarts_per_hour

OptionalInt

Per-job override of the Manager’s restart-rate ceiling: how many times this runtime may be re-placed within a trailing hour before the Manager gives up on it. Omit to use the configured default (failurePolicies, then the flat setting, then 6).

A RATE, not a lifetime count — the check is over a trailing hour, so a runtime that fails twice a day forever never trips it. That is deliberate: the ceiling exists to stop a hopeless job spinning, not to retire one that is occasionally unlucky.

essential

OptionalBool

Is losing this runtime fatal to the production it belongs to?

A production is a set of cooperating runtimes, so the default is yes: absent ⇒ essential. Setting it false marks a runtime the production can carry on without — a monitor, a recorder — which is otherwise only expressible by splitting it into its own production, and that is not available when the runtimes must share a node (co-placement does not apply across productions).

Governs BOTH ways a runtime is ultimately lost: exhausting the redeploy ceiling, and an on_runtime_failure of DROP. Those two used to disagree — the ceiling ended the production, DROP quietly did not — so this is the single answer to a question that previously had two.

OptionalBool rather than a bare bool deliberately: proto3’s zero value for a bool is false, which is the WRONG default here, and a field whose absence means the opposite of what it should is how quiet bugs start.

Member of

Message

Description

AutoPlacement

Marks a job as being under AutoManager’s bundle/placement control, and carries the inputs placement needs. Present iff AutoManager should place this job; absent means a plain (non-AutoManager) createJob. Wrapping the requirements this way reads more clearly than a bare optional requirements field, which a reader could mistake for "no constraints, place anywhere". Room to grow with future per-job placement policy.

BundleJobSpec