Commit aa0baeb2 authored by Klaus Aehlig's avatar Klaus Aehlig

Describe RATE_LIMIT as a job filter action

A feature often requested for the job queue is to limit certain
types of jobs. As the job filtering framework is the natural place
to host such a feature, explicitly describe rate limiting as one
of the supported actions.
Signed-off-by: default avatarKlaus Aehlig <aehlig@google.com>
Reviewed-by: default avatarPetr Pudlak <pudlak@google.com>
parent 92673172
......@@ -93,6 +93,14 @@ Filter rules are given by the following data.
rule. Such a rule will never have any direct or indirect effect,
but it can serve as documentation for a "normally present, but
currently disabled" rule.
- RATELIMIT ``n``, where ``n`` is a positive integer. The job will
be held in the queue while ``n`` or more jobs where this rule
applies are running. Jobs that are forked off from luxid are
considered running. Jobs already running when this rule is added
are not changed. Logically, this rule is applied job by job
sequentially, so that the number of jobs where this rule applies
is limited to ``n`` once the jobs running at rule addition have
finished.
- A reason trail, in the same format as reason trails for opcodes.
This allows to find out, which maintenance (or other reason) caused
......@@ -154,6 +162,14 @@ Canceling all queued instance creations and disallowing new such jobs.
'predicates': [['opcode', ['=', 'OP_ID', 'OP_INSTANCE_CREATE']]],
'action': 'REJECT'}
Limit the number of simultaneous instance disk replacements to 10 in order
to throttle replication traffic.
::
{'priority': 99,
'predicates': [['opcode', ['=', 'OP_ID', 'OP_INSTNCE_REPLACE_DISKS']]],
'action': ['RATE_LIMIT', 10]}
Interface
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment