Skip to content
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

podpools: fix synchronizing all running containers at start #965

Merged
merged 1 commit into from Dec 21, 2022

Conversation

askervin
Copy link
Contributor

This change makes podpools start similar to the balloons policy start: find all running containers in the system.

@codecov-commenter
Copy link

Codecov Report

Merging #965 (fd68471) into master (0b11e4a) will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master     #965   +/-   ##
=======================================
  Coverage   33.68%   33.68%           
=======================================
  Files          61       61           
  Lines        9156     9156           
=======================================
  Hits         3084     3084           
  Misses       5789     5789           
  Partials      283      283           
Impacted Files Coverage Δ
...manager/policy/builtin/podpools/podpools-policy.go 23.78% <0.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

jukkar
jukkar previously approved these changes Dec 20, 2022
This change makes podpools start similar to the balloons policy start:
find all running containers in the system.
verify-log-vs-metrics pod5:pod5c1 0 20
# There should be kube-apiserver, etcd etc. running on reserved CPUs as well,
# therefore allow a lot of CPU usage yet pod5 is not doing anything.
verify-log-vs-metrics pod5:pod5c1 0 100
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this somehow related?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, strongly. Now that the fix in policy Start() makes sure that kube-apiserver and etcd (among others) will be pinned to the reserved CPU - the same CPU where pod5 is scheduled too - the CPU load of that CPU can be much higher than at the time when this test was written. I got one failed test run because of that: the two processes may easily cause > 20% load on the only reserved CPU in our e2e VMs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks 👍

Copy link
Contributor

@marquiz marquiz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@marquiz marquiz merged commit 0ac1bc7 into intel:master Dec 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants