Arvados

The hardware runtime constraints are:

• min_ram_mb_per_node - The amount of RAM (MiB) available on each Node.
• min_scratch_mb_per_node - The amount of disk space (MiB) available for local caching on each Node.

Corresponding information about each node will lives in its info hash, and will be updated each ping.

Because we currently don't have a concept of Job priority, and it's not in this sprint, it seems best to stick pretty closely to Crunch's current FIFO strategy for working the Job queue. However, we need to take precautions to make sure that an unreasonably resource-large Job at the front of the queue doesn't prevent us from making progress on the rest of it. Plan: When the Job at the front of the queue can't be started because resource requirements aren't met, Crunch will wait for a few minutes to see if the Node Manager makes those resources available. If it does, great; proceed as normal. If not, continue through the queue and start the first job that can be run with available resources. Make sure that this wait only happens every so often, so lots of queue activity doesn't cause lots of waiting.