Revision 69bdebcc
Added by Eric Helms over 2 years ago
| manifests/init.pp | ||
|---|---|---|
|
# available, likely results in performance degradation due to I/O blocking and is not recommended in most cases. Modifying this parameter should
|
||
|
# be done incrementally with benchmarking at each step to determine an optimal value for your deployment.
|
||
|
#
|
||
|
# @param worker_ttl
|
||
|
# The number of seconds before a pulpcore worker should be considered lost.
|
||
|
#
|
||
|
# @param use_rq_tasking_system
|
||
|
# Use the older RQ workers tasking system instead of the newer PostgreSQL tasking system introduced in Pulpcore 3.14.
|
||
|
# Any benchmarking you did to optimize worker_count or other tasking related parameters will no longer be accurate after changing the tasking system.
|
||
| ... | ... | |
|
Pulpcore::ChecksumTypes $allowed_content_checksums = ['sha224', 'sha256', 'sha384', 'sha512'],
|
||
|
String[1] $remote_user_environ_name = 'HTTP_REMOTE_USER',
|
||
|
Integer[0] $worker_count = min(8, $facts['processors']['count']),
|
||
|
Optional[Integer[0]] $worker_ttl = undef,
|
||
|
Boolean $use_rq_tasking_system = false,
|
||
|
Boolean $service_enable = true,
|
||
|
Boolean $service_ensure = true,
|
||
Also available in: Unified diff
Fixes #33446: Allow setting the time until a worker is considered lost
This change implements the WORKER_TTL setting which lets Pulp decide
how long to wait for a worker to respond before considering it gone
and cleaning up it's database and re-assiging work.