You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit refactors the request processing pipeline, externalizing
saturation detection and criticality-based service differentiation
from the Scheduler. These responsibilities are now primarily managed by
the RequestControl.Director.
This change is a preparatory step for the introduction of a new
Flow Controller component, which will eventually absorb these admission
control duties.
Key changes include:
- Introduced `PreDispatch` method to `RequestControl.Director` It
utilizes the `SaturationDetector` for admission control of
non-critical requests and handles request criticality to determine if
saturation checks are bypassed.
- The saturation detection logic for dropping non-critical requests
is intentionally preserved within the `Director` at this stage.
This allows the option to bypass the future Flow Controller
component during its maturation, ensuring the existing saturation
and sheddable request behavior can be maintained as a fallback.
- Simplified the `Scheduler` to focus solely on preference-based
filtering and pod selection for requests that have already been
admitted by the `Director`.
- Removed the `HasCapacityFilter` and the distinct critical/sheddable
filter paths from the `Scheduler`'s internal logic. The `Scheduler`
now applies a single, unified preference filter chain (`lowLatencyFilter`)
to all incoming requests.
- Updated `main.go` to instantiate the `SaturationDetector` and
`RequestControl.Director`, wiring them into the request handling flow.
- Updated tests across `scheduler_test.go`, `director_test.go`, and
`filter_test.go` to align with the new component responsibilities,
adding additional coverage where necessary.
This refactoring leads to a cleaner architecture, making the `Scheduler`
a more focused component and centralizing initial admission control logic,
while paving the way for the future Flow Controller.
This is aligned with the direction in `0683-epp-architecture-proposal`
and should be nearly no-op in terms of EPP behavior.
0 commit comments