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
Assign openshift sdn traffic to system priority level #880
Conversation
- '*' | ||
subjects: | ||
- kind: ServiceAccount | ||
serviceAccount: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did i get the service account right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have two service accounts, sdn-controller
and sdn
. They're both system priority.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@squeed I added sdn-controller
as you suggested.
/cc @deads2k |
/retest |
1 similar comment
/retest |
One small change (both SAs) but otherwise seems reasonable. |
Looks reasonable |
/retest |
/lgtm |
@tkashem this is probably worth a backport. |
@tkashem can you rebase? Thanks! |
@dcbw rebase completed, it needs re-lgtm. |
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, squeed, tkashem The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
1 similar comment
/retest |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
11 similar comments
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
@tkashem: The following tests failed, say
Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
Um, this seems wrong; the |
PR: openshift#880 added a deployment stanza for a specific kubernetes feature, but only did that for openshift-sdn and not for ovn-kubernetes, moreover it added it in the wrong place independently of the network plugin being deployed Signed-off-by: Alexander Constantinescu <aconstan@redhat.com>
PR: openshift#880 added a deployment stanza for a specific kubernetes feature, but only did that for openshift-sdn and not for ovn-kubernetes, moreover it added it in the wrong place independently of the network plugin being deployed Signed-off-by: Alexander Constantinescu <aconstan@redhat.com>
@danwinship so this implies that we have to create a flowschema based on the network stack installed by the network operator. |
Yes, @danwinship is right. I shouldn't have approved this. |
Assign sdn traffic to
system
priority level, this will bring sdn traffic to the same priority level as kubelet traffic.Currently the kube-apiserver does not allocate the sdn traffic to any dedicated concurrency pool, so treating it no different than the default cluster workload. This change will allow the kube-apiserver to allocate the sdn traffic to a known priority level
system
shared by kubelet.For more information on priority and fairness - https://kubernetes.io/blog/2020/04/06/kubernetes-1-18-feature-api-priority-and-fairness-alpha/