feat: support node filtering based on hami-vnpu-core annotation - #1812
Merged
Conversation
…tioning Signed-off-by: ashergaga <1214443299@qq.com>
Signed-off-by: ashergaga <1214443299@qq.com>
Signed-off-by: ashergaga <1214443299@qq.com>
Signed-off-by: ashergaga <1214443299@qq.com>
Signed-off-by: ashergaga <1214443299@qq.com>
Signed-off-by: ashergaga <1214443299@qq.com>
Signed-off-by: ashergaga <1214443299@qq.com>
Signed-off-by: ashergaga <1214443299@qq.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces support for hami-core mode in the device allocation logic, including a new node selector annotation and validation checks to ensure compatibility between pod annotations and node capabilities. The review feedback highlights a typo in a comment, suggests simplifying the node annotation check, proposes using a logical XOR to reduce code duplication in the validation logic, and points out inconsistent indentation and alignment in the constant definitions.
Signed-off-by: ashergaga <1214443299@qq.com>
Signed-off-by: ashergaga <1214443299@qq.com>
Signed-off-by: ashergaga <1214443299@qq.com>
Codecov Report❌ Patch coverage is
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
Signed-off-by: ashergaga <1214443299@qq.com>
Signed-off-by: ashergaga <1214443299@qq.com>
DSFans2014
reviewed
Apr 29, 2026
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: archlitchi, ashergaga The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
mesutoezdil
pushed a commit
to mesutoezdil/HAMi
that referenced
this pull request
Jun 14, 2026
…ect-HAMi#1812) * feat(ascend): add ResourceCoreName to support hami-core compute partitioning Signed-off-by: ashergaga <1214443299@qq.com> * feat: add docs ascend910-hami-vnpu-support Signed-off-by: ashergaga <1214443299@qq.com> * feat: fix ai suggestion Signed-off-by: ashergaga <1214443299@qq.com> * feat: fix golangci lint Signed-off-by: ashergaga <1214443299@qq.com> * feat: fix format Signed-off-by: ashergaga <1214443299@qq.com> * feat: add unit test & proposal Signed-off-by: ashergaga <1214443299@qq.com> * feat: hami-vnpu-core ReadMe modify Signed-off-by: ashergaga <1214443299@qq.com> * feat: add failureReason ModeNotFit Signed-off-by: ashergaga <1214443299@qq.com> * feat: fix ai suggestion Signed-off-by: ashergaga <1214443299@qq.com> * feat: fix cilint Signed-off-by: ashergaga <1214443299@qq.com> * feat: fix unit test error Signed-off-by: ashergaga <1214443299@qq.com> * feat: add unit test Signed-off-by: ashergaga <1214443299@qq.com> * feat: fix cilint Signed-off-by: ashergaga <1214443299@qq.com> --------- Signed-off-by: ashergaga <1214443299@qq.com>
This was referenced Jul 2, 2026
Closed
Merged
Wangmin362
pushed a commit
to Wangmin362/HAMi
that referenced
this pull request
Jul 8, 2026
…ssing the node mode gate The node soft/hard exclusivity added in Project-HAMi#1812 rejects a mismatched pod with ModeNotFit, but the check is nested inside `request.Memreq > 0 && request.Memreq < totalMemPerCard && request.Nums > 0`. A whole-card memory request (Memreq == card capacity) or a memory-less request (Memreq == 0) never enters that block, so a hami-core (soft-split) pod can be scheduled onto a hard-split node, bypassing the exclusivity. Lift the soft-pod arm out of the memory-range condition: a pod that declares hami-core mode must land on a hami-core node regardless of how much memory it requests. The reverse arm (a legacy pod on a hami-core reserved node) stays inside the memory-range condition on purpose, so plain whole-card jobs are not rejected when a node -- or the global hamiVnpuCore default -- marks the node as hami-core. Verified on real hardware (8x Ascend 910B4): a hami-core pod requesting the whole card (32768 MiB) or no memory field is now held Pending with ModeNotFit on a hard node, matching the sub-capacity behaviour, while matching-mode and whole-card legacy requests keep scheduling. Signed-off-by: wangmin <wangmin@riseunion.io>
hami-robot Bot
pushed a commit
that referenced
this pull request
Jul 9, 2026
…ssing the node mode gate (#2029) * fix(ascend): stop whole-card/memory-less hami-core requests from bypassing the node mode gate The node soft/hard exclusivity added in #1812 rejects a mismatched pod with ModeNotFit, but the check is nested inside `request.Memreq > 0 && request.Memreq < totalMemPerCard && request.Nums > 0`. A whole-card memory request (Memreq == card capacity) or a memory-less request (Memreq == 0) never enters that block, so a hami-core (soft-split) pod can be scheduled onto a hard-split node, bypassing the exclusivity. Lift the soft-pod arm out of the memory-range condition: a pod that declares hami-core mode must land on a hami-core node regardless of how much memory it requests. The reverse arm (a legacy pod on a hami-core reserved node) stays inside the memory-range condition on purpose, so plain whole-card jobs are not rejected when a node -- or the global hamiVnpuCore default -- marks the node as hami-core. Verified on real hardware (8x Ascend 910B4): a hami-core pod requesting the whole card (32768 MiB) or no memory field is now held Pending with ModeNotFit on a hard node, matching the sub-capacity behaviour, while matching-mode and whole-card legacy requests keep scheduling. Signed-off-by: wangmin <wangmin@riseunion.io> * address review: make the legacy-vNPU filter log nil-safe Use klog.KObj(pod) instead of dereferencing nodeInfo.Node.Name and pod.Name directly, matching the hami-core arm above and avoiding a potential nil dereference (both are guarded as possibly nil earlier in Fit). Signed-off-by: wangmin <wangmin@riseunion.io> * address review: drop verbose comments and internal markers Signed-off-by: wangmin <wangmin@riseunion.io> --------- Signed-off-by: wangmin <wangmin@riseunion.io> Co-authored-by: wangmin <wangmin@riseunion.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR enhances the
hami-schedulerfiltering strategy by enabling it to perceive the state ofhami-vnpu-coreon a node-by-node basis.Core Logic:
During the Predicate (Filter) phase, the scheduler now retrieves and inspects the
hami-vnpu-coreannotation on the Node. If a Pod's annotation declareshuawei.com/vnpu-mod: hami-core, the scheduler will strictly match nodes that have enabled thehami-vnpu-coreannotation.