-
Notifications
You must be signed in to change notification settings - Fork 60
cincinnati/plugins: add "assign_wariness" plugin #130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lucab The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
d1a66a8 to
4068ab7
Compare
|
/hold This is temporarily based on #129, as it uses |
|
Out of band discussion: openshift systems uses floats from 0.0 to 1.0, it would be good to make the two compatible. |
4068ab7 to
23ab8cd
Compare
|
@steveej I've updated this PR to use floats within the range The overall algorithm that will consume this value is sketched at coreos/zincati#82 and aligns with the current draft of OpenShift "risk appetite" logic. |
This implements a new "assign_wariness" plugin, which is mainly meant to be used on policy-engine side. This plugin ensures that each request has an attached "wariness" score for throttling purposes, which can be either provided by the client or computed server-side based on some other client input paramenters. Wariness value can be then used by other plugins to enact (static or dynamic) throttling decisions. It has the property that a set of request parameters will always result in the same wariness value, for stable/deterministic bucketing.
23ab8cd to
7668536
Compare
|
/hold cancel Testing permissions |
|
/hold |
|
@lucab: PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@lucab: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
@lucab: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This implements a new "assign_wariness" plugin, which is mainly meant
to be used on policy-engine side.
This plugin ensures that each request has an attached "wariness" score
for throttling purposes, which can be either provided by the client
or computed server-side based on some other client input paramenters.
Wariness value can be then used by other plugins to enact (static or dynamic)
throttling decisions. It has the property that a set of request parameters
will always result in the same wariness value, for stable/deterministic
bucketing.
/cc @steveej