Project-HAMi/HAMi

Task description PR #3189 added the helm-docs workflow. Issue #3055 is now closed. This issue tracks the remaining work on Chart values documentation. Many comments in charts/hami/values.yaml still use bitnami/readme-generator-for-helm style @param annotations(comments). Other values have no description, or have comments that need correction. The generated table in charts/hami/README.md currently includes only values with helm-docs descriptions. We need help converting existing comments, adding missing descriptions, and correcting inaccurate descriptions. The goal is a useful values reference that matches the Chart's actual behavior. Please take one section at a time. You do not need to document the whole file in one PR. Suggested scopes include but not limited: Global settings and release name or namespace overrides. OpenShift, SELinux, and PodSecurityPolicy settings. One devices.<vendor> section per PR, such as devices.nvidia, devices.ascend, or devices.mthreads. other values... Su

What would you like to be added: Consolidate the dashboard in HAMi/dashboard with the existing website template, and maintain the unified dashboard in Project-HAMi/website. Consolidate useful panels, remove duplication, and align queries with supported HAMi metrics. Update the English and Chinese documentation with prerequisites, import instructions, and HAMi/Grafana compatibility requirements, including any DCGM dependencies. Preserve relevant validation checks and update HAMi’s references. Delete the entire dashboards/ directory from HAMi after the unified dashboard and updated documentation are published on the website. Why is this needed: The two repositories currently provide different dashboard templates and instructions. Consolidating them will reduce duplicate maintenance and provide a consistent monitoring experience, following the migration plan discussed in the HAMi community meeting. Anything else we need to know?: Verify that the unified dashboard imports successfully

What happened: AWSNeuronDevices.PatchAnnotations (pkg/device/awsneuron/device.go:203-261) builds the AWSNeuronAssignedIndex annotation inside a loop over devlist (one entry per container), but the value accumulator is declared outside the loop and never reset per container, and the annotation key is reassigned on every iteration. For a pod with two or more containers each requesting an AWS Neuron device, the resulting annotation reflects an accumulated/ambiguous value rather than a correct per-container mapping. This is the same defect class reported and fixed for kunlun and mthreads in #2463 ("PatchAnnotations overwrites per-container device index for multi-container pods"), which explicitly scoped itself to those two backends. I checked the remaining backends' PatchAnnotations implementations directly: ascend, cambricon, hygon, amd, metax, biren, vastai, and enflame's GCU path all write only the container-delimited EncodePodSingleDevice blob or explicitly guard with if _, exists := .

What happened: Scheduler.Filter in pkg/scheduler/scheduler.go takes the live filter path whenever args.Nodes is nil (:1038), and that path dereferences *args.NodeNames in two places without a nil check: :1061 — fmt.Errorf("no available node, %d nodes do not meet", len(*args.NodeNames)) :1100 — genSuccessMsg(len(*args.NodeNames), ...) ExtenderArgs can carry neither Nodes nor NodeNames. getNodesUsage(nil, pod) returns an empty map without an error, so calcScore yields an empty node list and execution reaches :1061: panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation] pkg/scheduler/scheduler.go:1061 Because this runs on the extender's HTTP goroutine, the panic terminates the scheduler process rather than failing the single request that caused it. The function already has a nil-guarding nodeNamesLen() helper (:607) and uses it elsewhere — these two call sites just don't. What you expected to happen: A filter request with

What happened: AMDDevices.MutateAdmission returns true for a container that requests only amd.com/gpu-mem and/or amd.com/gpu-core-pct without the amd.com/gpu count — and also for an invalid count (0, negative, fractional, or > math.MaxInt32). Because the mutating webhook sets pod.Spec.SchedulerName to the HAMi scheduler whenever any backend's MutateAdmission returns true, such a pod is routed into the HAMi path. But GenerateResourceRequests and LockNode both key off the count resource, so they produce an empty request (Nums=0) and take no node lock. The result: the namespace GPU ResourceQuota check is skipped (fitResourceQuota continues on Nums==0), the scheduler filter passes on every node (hasHAMiResource stays false), the pod binds with no AMD device reserved and no hami.io/amd-devices-allocated annotation. No error surfaces anywhere. AMD is the only backend with this gap — nvidia backfills the count in mutateContainerResource, and metax checks the count in both admission and