TOP LEVEL KEYS (HOSTNAMES)

All top level keys are hostnames. When the config is read the settings for the current hostname will be used. If the hostname is not defined then the "DEFAULT" host will be read. If there is no "DEFAULT" host defined an exception will be thrown.

CONFIG OPTIONS

Each option must be specified under a hostname, none of these are valid on their own.

state_file: /path/to/shared/state/file

REQUIRED

This specifies the path to the shared state file. All yath processes by all users who are sharing slots need read+write access to this file.

state_umask: 0007

Defaults to 0007. Used to set the umask of the state file as well as the lock file.

max_slots: 8

Max slots system-wide for all users to share.

max_slots_per_run: 4

Max slots a specific test run can use.

min_slots_per_run: 0

Minimum slots per run.

Set this if you want to make sure that all runs get at least N slots, EVEN IF IT MEANS GOING OVER THE SYSTEM-WIDE MAXIMUM!.

This defaults to 0.

max_slots_per_job: 2

Max slots a specific test job (test file) can use.

default_slots_per_run: 4

If the user does not specify a number of slots, use this as the default.

default_slots_per_job: 2

If the user does not specify a number of job slots, use this as the default.

algorithm: fair

algorithm: first

algorithm: Fully::Qualified::Module::function_name

Algorithm to use when assigning slots. 'fair' is the default.

ALGORITHMS

These are algorithms that are used to decide which test runs get which slots.

fair

DEFAULT

This algorithm tries to balance slots so that all runs share an equal fraction of available slots. If there are not enough slots to go around then priority goes to oldest runs, followed by oldest requests.

first

Priority goes to the oldest run, followed by the next oldest, etc. If the run age is not sufficient to sort requests this will fall back to 'fair'.

This is mainly useful for CI systems or batched test boxes. This will give priority to the first test run started, so additional test runs will not consume slots the first run wants to use, but if the first run is winding down and does not need all the slots, the second test run can start using only the spare slots.

Use this with ordered test runs where you do not want a purely serial run order.

Fully::Qualified::Module::function_name

You can specify custom algorithms by giving fully qualified subroutine names.

Example custom algorithm:

    sub custom_sort {
        my ($state_object, $state_data, $a, $b) = @_;
        return 1 if a_should_come_first($a, $b);
        return -1 if b_should_come_first($a, $b);
        return 0 if both_have_same_priority($a, $b);
        # *shrug*
        return 0;
    }

Ultimately this is used in a "sort()" call, usual rules apply, return should be 1, 0, or -1. $a and $b are the 2 items being compared. $state_object is an instance of "Test2::Harness::Runner::Resource::SharedJobSlots::State". $state_data is a hashref like you get from "$state_object->state()" which is useful if you want to know how many slots each runner is using for a 'fair' style algorth.

Take a look at the "request_sort_XXX" methods on "Test2::Harness::Runner::Resource::SharedJobSlots::State" which implement the 3 original sorting methods.