ganeti
Safe HaskellNone

Ganeti.JQScheduler.ReasonRateLimiting

Description

Ad-hoc rate limiting for the JQScheduler based on reason trails.

Synopsis

Documentation

type AdHocReasonKey = String Source #

Ad-hoc rate limiting buckets are identified by the combination `REASONSTRING:n`, so "mybucket:3" and "mybucket:4" are different buckets.

parseReasonRateLimit :: MonadFail m => String -> m (String, Int) Source #

Parses an ad-hoc rate limit from a reason trail, as defined under "Ad-Hoc Rate Limiting" in `doc/design-optables.rst`.

The parse succeeds only on reasons of form `rate-limit:n:REASONSTRING` where n is a positive integer and REASONSTRING is an arbitrary string (may include spaces).

labelCountMapFromJob :: QueuedJob -> CountMap (String, Int) Source #

Computes the bucket slots required by a job, also extracting how many slots are available from the reason rate limits in the job reason trails.

A job can have multiple OpCodes, and the ReasonTrails can be different for each OpCode. The OpCodes of a job are run sequentially, so a job can only take 1 slot. Thus a job takes part in a set of buckets, requiring 1 slot in each of them.

countMapFromJob :: QueuedJob -> CountMap AdHocReasonKey Source #

Computes the bucket slots required by a job.

slotMapFromJobs :: [QueuedJob] -> SlotMap AdHocReasonKey Source #

Map of how many slots are in use for a given bucket, for a list of jobs. The slot limits are taken from the ad-hoc reason rate limiting strings.

unoccupiedSlotMapFromJobs :: [QueuedJob] -> SlotMap AdHocReasonKey Source #

Like slotMapFromJobs, but setting all occupation counts to 0. Useful to find what the bucket limits of a set of jobs are.

reasonRateLimit :: Queue -> [JobWithStat] -> [JobWithStat] Source #

Implements ad-hoc rate limiting using the reason trail as specified in `doc/design-optables.rst`.

Reasons of form `rate-limit:n:REASONSTRING` define buckets that limit how many jobs with that reason can be running at the same time to a positive integer n of available slots.

The used buckets map is currently not cached across selectJobsToRun invocations because the number of running jobs is typically small (< 100).