-
Notifications
You must be signed in to change notification settings - Fork 206
refactor: [Scale from Zero] Introduce PodLocator #1950
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -22,6 +22,16 @@ import ( | |
| "sigs.k8s.io/gateway-api-inference-extension/pkg/epp/backend/metrics" | ||
| ) | ||
|
|
||
| // PodLocator defines the contract for a component that resolves the set of candidate pods for a request based on its | ||
| // metadata (e.g., subsetting). | ||
| // | ||
| // This interface allows the Flow Controller to fetch a fresh list of pods dynamically during the dispatch cycle, | ||
| // enabling support for "Scale-from-Zero" scenarios where pods may not exist when the request is first enqueued. | ||
| type PodLocator interface { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. why not keep the candidates term instead? like
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are you just referring to the interface name here? Both of these seem better to me.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, referring to the name.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can merge this as is and then rename after the other PR merges just so we don't cause conflicts with the second PR. |
||
| // Locate returns a list of pod metrics that match the criteria defined in the request metadata. | ||
| Locate(ctx context.Context, requestMetadata map[string]any) []metrics.PodMetrics | ||
| } | ||
|
|
||
| // SaturationDetector defines the contract for a component that provides real-time load signals to the | ||
| // `controller.FlowController`. | ||
| // | ||
|
|
||
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.
I am defining this interface within the Flow Control contracts package as it will serve as the primary contract for lazy candidate resolution during the dispatch cycle.
Crucially, this abstraction decouples the core request lifecycle from specific upstream filtering logic. While the current implementation handles Envoy subsetting, isolating this behavior behind an interface paves the way for promoting it to an EPP Extension Point. This would allow adopters to inject environment-specific or vendor-customized discovery mechanisms in the future without polluting the core directory.