Crunch2 dispatch¶

Design sketch¶

sLURm to crunCH = "Lurch"

• Use websockets to listen for container events (new containers added, priority changes)

Flow:

• Monitor containers table.
  1. When a new container appears, claim it
  2. Try to run immediately srun --immediate --share --output=none --error=none --input=none
  3. If unable to salloc, post a request for a new node to node manager (mechanism TBD)
  4. Dispatch the job srun --jobid
• Monitor slurm job status.

Decision points:

• What language? (Python/Go/Ruby)
  • Go will require a Go websockets client

Notes¶

Some discussion notes from https://dev.arvados.org/issues/6429 and https://dev.arvados.org/issues/6518

Interaction with node manager¶

Suggest writing crunch 2 job dispatcher as a new set of actors in node manger.

This would enable us to solve the question of communication between the scheduler and cloud node management (#6520).

Node manager already has a lot of the framework we will want like concurrency (can have one actor per job) and a configuration system.

Different schedulers (slurm, sge, kubernetes) can be implemented as modules similarly to how different cloud providers are supported now.

If we don't actually combine them, we should at least move the logic of deciding how many and what size nodes to run from the node manager to the dispatcher; the dispatcher can then communicate its wishlist to node manager.

Interaction with API¶

More ideas:

Have a "dispatchers" table. Dispatcher processes are responsible for pinging the API server similar to how it is done for nodes to show they are alive.

A dispatcher claims a container by setting "dispatcher" field to it's UUID. This field can only be set once and that locks the record so that only the dispatcher can update it.

If a dispatcher stops pinging, the containers it has claimed should be marked as TempFail.

Dispatchers should be able to annotate containers (preferably through links) for example "I can't run this because I don't have any nodes with 40 GiB of RAM".

Retry¶

How do we handle failure? Is the dispatcher required to retry containers that fail, or is the dispatcher a "best effort" service and the API decides to retry by scheduling a new container?

Currently the container_uuid field only holds a single container_uuid at a time. If the API schedules a new container, does that mean any container requests associated with that container get updated with the new container?

If the container_uuid field only holds one container at a time, and container don't link back to the container requests that created, then we don't have a way to record of past attempts to fulfill this request. This means we don't have anything to check against container_count_max. A few possible solutions:

• Make container_uuid an array of containers created to fulfill a given container request (this introduces complexity)
• Decrement container_count_max on the request when submitting a new container
• Compute content address of the container request and discover containers with that content address. This would conflict with "no reuse" or "impure" requests which are supposed to ignore past execution history. Could solve this by salting the content address with a timestamp; "no reuse" containers would never ever be reusable which might be fine.

I think we should distinguish between infrastructure failure and task failure by distinguishing between "TempFail" and "PermFail" in the container state. "TempFail" shouldn't count againt the container_count_max count, or alternately we only honor container_count_max for "TempFail" tasks and don't retry "PermFail".

Ideally, "TempFail" containers should retry forever, but with a backoff. One way to do the backoff is to schedule the container to run at a specific time in the future.

Scheduling¶

Having a field specifying "wait until time X to run this container" would be generally useful for cron-style tasks.

State changes¶

Container request:

	priority 0	priority > 0
Uncommitted	nothing	nothing
Committed	set container priority to max(all request priority)	set container priority to max(all request priority)
Final	invalid	invalid

When a container request goes to the "committed" state, it is assigned a container.

Container:

	priority 0	priority > 0
Queued	Desire change state to "Cancelled"	Desire to change change state to "Running"
Running	Desire change state to "Cancelled"	nothing
Complete	invalid	invalid
Cancelled	invalid	invalid

When the container goes to either the "complete" or "cancelled" state, any associated container requests go to "final" state.

Claims¶

Have a field "claimed_by_uuid" on the Container record. A queued container is claimed by a dispatcher process via an atomic "claim" operation. A claim can be released if the container is still in the Queued state.

The container record cannot be updated by anyone except the owner of the claim.