Config files for shared slots must be yaml file, they must also be parsable by YAML::Tiny, which
implements a subset of yaml.
Here is an example config file:
---
DEFAULT:
state_file: /tmp/yath-slot-state
max_slots: 8
max_slots_per_job: 2
max_slots_per_run: 6
myhostname:
state_file: /tmp/myhostname-slot-state
max_slots: 16
max_slots_per_job: 4
max_slots_per_run: 12
TOPLEVELKEYS(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.
CONFIGOPTIONS
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, EVENIFITMEANSGOINGOVERTHESYSTEM-WIDEMAXIMUM!.
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.
Install Now
PNG Icons
