fix: accept the pre-v2.9.0 HAMi device config layout

[Wangmin362]

What type of PR is this?
/kind bug

What this PR does / why we need it:
HAMi v2.9.0 moved the Ascend chip list in the hami-scheduler-device ConfigMap from vnpus to vnpus.configs, and this plugin followed in cc588e4. It now only parses the new layout, so against HAMi v2.7.0 - v2.8.3, which all write vnpus as a list, it dies at startup:

load config failed, error is failed to load config from /device-config.yaml:
error unmarshaling JSON: while decoding JSON: json: cannot unmarshal array
into Go struct field Config.vnpus of type internal.VNPUsConfig

docs/hami.md still lists HAMi >= 2.7.0 as enough for template-based hard slicing.

LoadConfig now retries with the old layout and warns, but only on the UnmarshalTypeError that layout produces (an array fed to vnpus). Every other failure keeps its own error.

docs/hami.md also gains a note that merging this repo's vnpus: block into a pre-v2.9.0 HAMi ConfigMap must keep that ConfigMap's own list layout, since its scheduler cannot read vnpus.configs.

Which issue(s) this PR fixes:
NONE

Special notes for your reviewer:
Nothing else needs changing for an older HAMi: the register annotation, the devices-to-allocate encoding, the huawei.com/<commonWord> runtime info and the bind-phase handling are identical between v2.8.x and master.

Checked on an Ascend 910B4 node (8 cards, driver 25.5.1): fed the old layout, config loading fails before the patch and works after, resolving the same chip config and the same 8 devices as the new layout.

AI assistance disclosure: this PR was written primarily by Claude Code. I reviewed the change, the tests and the hardware run myself.

Does this PR introduce a user-facing change?:
ascend-device-plugin again accepts the device-config.yaml layout of HAMi v2.7.0 - v2.8.x instead of failing to start against it.

Summary by CodeRabbit

• New Features

  • Added support for HAMi v2.9.0’s nested vnpus.configs configuration format.
  • Maintained compatibility with legacy vnpus configurations, with a warning when the older format is detected.
  • Improved chip matching, virtual device count calculation, and hamiVnpuCore handling.

• Documentation

  • Updated English and Chinese deployment guidance, including version-specific configuration requirements.

• Bug Fixes

  • Added clearer handling for missing chips, empty configurations, malformed input, and invalid configuration types.

[hami-robot]

@Wangmin362: The label(s) kind/bug cannot be applied, because the repository doesn't have them.

Details

In response to this:

What type of PR is this?
/kind bug

What this PR does / why we need it:
HAMi v2.9.0 moved the Ascend chip list in the hami-scheduler-device ConfigMap from vnpus to vnpus.configs, and this plugin followed in cc588e4. It now only parses the new layout, so against HAMi v2.7.0 - v2.8.3, which all write vnpus as a list, it dies at startup:

load config failed, error is failed to load config from /device-config.yaml:
error unmarshaling JSON: while decoding JSON: json: cannot unmarshal array
into Go struct field Config.vnpus of type internal.VNPUsConfig

docs/hami.md still lists HAMi >= 2.7.0 as enough for template-based hard slicing.

LoadConfig now retries with the old layout and warns, but only on the UnmarshalTypeError that layout produces (an array fed to vnpus). Every other failure keeps its own error.

docs/hami.md also gains a note that merging this repo's vnpus: block into a pre-v2.9.0 HAMi ConfigMap must keep that ConfigMap's own list layout, since its scheduler cannot read vnpus.configs.

Which issue(s) this PR fixes:
NONE

Special notes for your reviewer:
Nothing else needs changing for an older HAMi: the register annotation, the devices-to-allocate encoding, the huawei.com/<commonWord> runtime info and the bind-phase handling are identical between v2.8.x and master.

Checked on an Ascend 910B4 node (8 cards, driver 25.5.1): fed the old layout, config loading fails before the patch and works after, resolving the same chip config and the same 8 devices as the new layout.

AI assistance disclosure: this PR was written primarily by Claude Code. I reviewed the change, the tests and the hardware run myself.

Does this PR introduce a user-facing change?:
ascend-device-plugin again accepts the device-config.yaml layout of HAMi v2.7.0 - v2.8.x instead of failing to start against it.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 1f377314-e2b7-453a-a0b2-d1dc98844169

📥 Commits

Reviewing files that changed from the base of the PR and between 771e19f and df808ee.

📒 Files selected for processing (5)

• docs/hami.md
• docs/hami_cn.md
• internal/manager/manager_test.go
• internal/vnpu.go
• internal/vnpu_test.go

Included review availability: Your plan includes up to 1 review per rolling hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

HAMi configuration loading now supports both the vnpus.configs layout introduced in v2.9.0 and the legacy vnpus layout. Tests cover successful loading, validation errors, chip selection, and manager integration. Documentation describes version compatibility.

Changes

HAMi configuration compatibility

Layer / File(s)	Summary
Backward-compatible configuration loading internal/vnpu.go, internal/vnpu_test.go, docs/hami.md, docs/hami_cn.md	LoadConfig accepts nested and legacy VNPU layouts. Legacy fallback logs a warning. Tests cover decoding, precedence, empty configurations, and error paths. Documentation adds HAMi version guidance.
Manager configuration integration tests internal/manager/manager_test.go	Tests load temporary configurations, select matching chips, verify resource values and vDevice counts, and validate missing-chip errors.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Merge Risk: ⚪ Minimal · up to df808

This change restores compatibility with older HAMi device configuration layouts while preserving the existing layout behavior; no actionable merge-blocking risk remains beyond normal checks and review.

Sequence Diagram(s)

sequenceDiagram
  participant ConfigFile
  participant LoadConfig
  participant isLegacyVNPUsLayout
  participant Logger
  ConfigFile->>LoadConfig: Provide YAML configuration
  LoadConfig->>isLegacyVNPUsLayout: Inspect vnpus type mismatch
  isLegacyVNPUsLayout-->>LoadConfig: Identify legacy list layout
  LoadConfig->>Logger: Record legacy-layout warning
  LoadConfig-->>ConfigFile: Return current Config structure

Loading

Possibly related PRs

• Project-HAMi/ascend-device-plugin#118: Updates the same HAMi configuration documentation.

Suggested labels: enhancement

Suggested reviewers: archlitchi

Poem

I’m a rabbit guarding YAML bright,
Two layouts now hop through the night.
Old chips warn before they land,
New configs bloom as planned.
Tests nibble every error tight.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: support for the pre-v2.9.0 HAMi device configuration layout.
Docstring Coverage	✅ Passed	Docstring coverage is 83.33% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[archlitchi]

/lgtm

[hami-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: archlitchi, Wangmin362

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [archlitchi]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment