[Feature] Add resource mapping for Huawei Ascend NPUs

[bakhovaddinov]

This adds prefix-based resource mapping for Huawei Ascend NPUs to properly inject Ray NPU limits. Resolves #5039.

Why are these changes needed?

This PR adds native support for Huawei Ascend NPUs in KubeRay by mapping Kubernetes Ascend device resources to Ray's logical NPU resource.

Because Huawei device plugins and virtualization schedulers (like HAMi) expose several variations of resource names depending on the chip model and slicing (e.g., huawei.com/Ascend910B, huawei.com/ascend-1980, huawei.com/npu), this change introduces a case-insensitive prefix check (huawei.com/ascend) instead of hardcoding exact exact model names in the customAcceleratorToRayResourceMap.

This ensures that the operator correctly parses the limits and automatically injects --resources='{"NPU": X}' into the Ray worker startup parameters for all current and future Ascend hardware generations.

The refactor also unifies the accelerator resource mapping logic across both code paths that populate rayStartParams (top-level Resources field and container resources.limits). Previously, custom accelerators like google.com/tpu and aws.amazon.com/neuroncore could end up under different keys in --resources depending on which field was used. Both paths now go through getCustomAcceleratorRayResourceName, producing consistent Ray resource names (TPU, neuron_cores) regardless of the input field.

Related issue number

Closes #5039

Labels

• If this PR has user-facing changes that require documentation updates at release time, I have added the doc-updates-required label.
• If this PR contains breaking changes, I have added the breaking-change label.

Checks

• I've made sure the tests are passing.
• Testing Strategy
  • Unit tests
  • Manual tests
  • This PR is not tested :(

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 9f61605. Configure here.}

[bakhovaddinov]

@win5923 @machichima I think the failed test in the pipeline is flaky or something. Any way to merge without it passing or trigger a new run?

[win5923]

Have you rebase onto latest main branch? We recently fixed some flaky tests.

[bakhovaddinov]

Have you rebase onto latest main branch? We recently fixed some flaky tests.

sorry, I was afk. I've rebased just now and now a new test fails

[win5923]

Sorry for the inconvenience. We have a PR fixes this. You can rebase again once #5084 is merged.

[bakhovaddinov]

@win5923 @machichima @rueian @andrewsykim can we merge this please?

[machichima]

Overall LGTM, just few comments

[machichima]

LGTM! cc @rueian or @andrewsykim to merge. The CI failure is not related to this PR

[bakhovaddinov]

LGTM! cc @rueian or @andrewsykim to merge. The CI failure is not related to this PR

is there an issue regarding the CI failure problem? It's quite annoying honestly, I could have a look at the weekends

[machichima]

is there an issue regarding the CI failure problem? It's quite annoying honestly, I could have a look at the weekends

Yeah agree. There's an issue for this #4782 and someone is working on it

[bakhovaddinov]

@rueian @andrewsykim could we merge please?

[bakhovaddinov]

@machichima @win5923 @rueian @andrewsykim I'm sorry to bother you again, guys. Is there anything I can do to make this PR closer to merge? Kinda confused if the problem is on my end or CI related. I've triggered CI a few times, something keeps failing. Does it prevent the merge?