feat: implement forced destination behavior in Nova external scheduler - #1163
Conversation
Signed-off-by: Markus Wieland <markus.wieland@sap.com>
|
Warning Review limit reachedNext included review available in 6 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Signed-off-by: Markus Wieland <markus.wieland@sap.com>
Signed-off-by: Markus Wieland <markus.wieland@sap.com>
Signed-off-by: Markus Wieland <markus.wieland@sap.com>
There was a problem hiding this comment.
Pull request overview
This PR adds support for Nova’s “forced destination” scheduling behavior to Cortex’s Nova external scheduler API. When force_hosts/force_nodes are set and _nova_check_type is not present, Cortex bypasses its pipeline/filter execution and returns only the forced destinations, matching Nova’s native behavior and unblocking flows like onboarding tests.
Changes:
- Add forced-destination detection and forced-host selection logic to Nova external scheduler request handling.
- Introduce a
forcedDestinationEnabledkill-switch (default enabled) to toggle the forced-destination bypass behavior. - Add unit tests for forced-destination behavior and wire the new config into the cortex-nova Helm bundle values.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| internal/scheduling/nova/external_scheduler_api.go | Adds config toggle and early-return path to bypass pipeline for forced-destination requests. |
| internal/scheduling/nova/external_scheduler_api_test.go | Adds tests for forced-destination enabled/disabled behavior. |
| helm/bundles/cortex-nova/values.yaml | Exposes forcedDestinationEnabled in bundle values with documentation. |
| api/external/nova/messages.go | Adds request helpers to detect forced-destination and compute the forced host list. |
| api/external/nova/messages_test.go | Adds unit tests for forced-destination detection and host matching behavior. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Signed-off-by: Markus Wieland <wie.markus@web.de>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.
Suppressed comments (2)
Previously missed (1) — in code that hasn't changed since the last review.
api/external/nova/messages.go:110
- IsForcedDestination() currently treats any error from GetSchedulerHintStr("_nova_check_type") as if the hint is absent, which can incorrectly skip filters when the hint key is present but has an unexpected type. That diverges from the documented behavior (“skip only when _nova_check_type is not set”). Consider only skipping when the hint is truly missing/empty; if the key exists but cannot be parsed, fall back to not skipping (safer default).
// If _nova_check_type is set (e.g. rebuild/evacuate/resize), the host is
// forced but must still be validated by the filters, so don't skip.
checkType, err := r.Spec.Data.GetSchedulerHintStr("_nova_check_type")
if err == nil && checkType != "" {
return false
internal/scheduling/nova/external_scheduler_api_test.go:479
- TestHTTPAPI_NovaExternalScheduler_ForcedDestinationDisabled only asserts that the delegate was called, but it doesn’t assert that the handler actually returned a successful HTTP response. Adding a status-code assertion helps catch regressions where the delegate is invoked but the request still fails (e.g., encoding/response errors).
api.NovaExternalScheduler(w, req)
if !delegateCalled {
t.Error("delegate should be called when forced destination is disabled")
}
Test Coverage ReportTest Coverage 📊: 72.4% |
Cortex does not yet support Nova's forced-destination behavior. This causes problems for flows like onboarding tests that force a specific host, because:
so the VM can never land on the forced host.
This PR replicates Nova's forced-destination behavior (see sapcc/nova).
When
force_hostsorforce_nodesis set in the request spec and no_nova_check_typeis present in scheduler_hints, the filter/weigher pipeline is skipped entirely and only the forced destinations are returned.I added a kill switch to the config
forcedDestinationEnabled. That way, if something breaks we can easily disable it again without doing an emergency deployment.