-
Notifications
You must be signed in to change notification settings - Fork 134
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
[YUNIKORN-1844] PreEnqueue plugin implementation #626
Conversation
120e228
to
616a3ec
Compare
Codecov Report
@@ Coverage Diff @@
## master #626 +/- ##
==========================================
- Coverage 70.86% 70.82% -0.05%
==========================================
Files 50 52 +2
Lines 8194 8251 +57
==========================================
+ Hits 5807 5844 +37
- Misses 2184 2201 +17
- Partials 203 206 +3
... and 5 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
bb4e518
to
e03f4ee
Compare
e03f4ee
to
b36ef02
Compare
Code looks good. I was wondering if we can refactor the code a bit and move the event setup. One comment on the code: instead of passing around |
The predicate manager is the place in the code where we instantiate and manage the default scheduler plugins. It is used by both the standard and plugin mode and so is its own package. The EventsToRegister() function was previously a static list but this is fragile and doesn't cover all the events that the various plugins might need. Restructuring this is going to cause ugly circular dependencies. As for types.UID, that is what is returned from the Kubernetes functions - I refactored out some common methods and decided that one cast inside the method was cleaner than casting at every call site. |
This is the change when we cast early: it allows a further change as the
|
I moved the scheduler_plugin.go file into the plugin top level directory without an issue all unit tests and compilations still ran and no circular dependencies were seen. That is a simple refactor.Scheduler plugin belongs in plugin... Further refactor we can push out but I think the predicate manager should become a single instance outside of the context. |
I still don't like moving the scheduler_plugin code to plugins. The plugins package predates the scheduler plugin functionality and actually refers to plugins to YuniKorn itself (general, sparkoperator, etc.) so the meaning is inverted. When I implemented the scheduler plugin in the first place I explicitly did NOT reuse the package to avoid confusion. |
Seems I was operating from memory rather than actually looking at the code. I agree, moving scheduler_plugin.go to pkg/plugin makes sense. The appmgmt stuff is already separated out. |
32470b7
to
5bc7ed8
Compare
Updated PR based on review comments, and rebased on latest master. |
@wilfred-s can you re-review? |
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.
LGTM
What is this PR for?
Implements the PreEnqueue() scheduling hook for the scheduler plugin implementation. This allows gating Pods that are not yet ready for scheduling due to queue pressure.
What type of PR is it?
Todos
What is the Jira issue?
https://issues.apache.org/jira/browse/YUNIKORN-1844
How should this be tested?
E2E scheduling tests should continue to succeed.
Screenshots (if appropriate)
Questions: