volcano-sh/volcano

What is the problem you're trying to solve Volcano release-1.17 needs to support Kubernetes v1.37. Upgrade the Kubernetes dependencies to the corresponding v1.37.x-compatible versions and ensure Volcano works correctly on Kubernetes v1.37. Describe the solution you'd like Follow the Kubernetes adaptation guide to upgrade the dependencies and address compatibility changes: https://github.com/volcano-sh/volcano/blob/master/docs/design/adapt-k8s-todo.md Update Kubernetes dependencies in the main repository and the staging APIs module (staging/src/volcano.sh/apis/go.mod) to the versions corresponding to Kubernetes v1.37.x. Update Go and related build/code-generation tools as required by the target Kubernetes version, regenerate affected code, and fix API or scheduler compatibility changes. Run code-generation verification, unit tests, and E2E tests on Kubernetes v1.37; verify compatibility with the other Kubernetes versions supported by release-1.17. Update the Kubernetes compatibility do

Background Users need clear, verified guidance on how to configure and use the gangpreempt and gangreclaimactions. Recent questions, including #5827, show that it is currently difficult to determine which Volcano versions support these actions, how they differ from the legacy preempt and reclaim actions, and which plugins must be enabled for them to work correctly. Documentation scope Add user documentation that covers: The purpose and behavior of gangpreempt and gangreclaim. The scenarios each action is intended for, including same-queue priority preemption and cross-queue resource reclamation where applicable. Supported Volcano versions or images and any known limitations. A complete, recommended scheduler configuration containing a validated combination of actions and plugins. End-to-end examples with queues, priorities, PodGroups or Volcano Jobs, and the expected scheduling and eviction behavior. A clear explanation that users may add other plugins according to their own schedulin

Description HAMi DeviceShare configuration is applied when the deviceshare plugin is created for a scheduling session. However, the scheduler cache starts beforehand and may create NodeInfo objects while hami.AscendHAMiVNPUEnable is still false. In that case, the cached NodeInfo does not contain HAMi AscendDevices in NodeInfo.Others. After DeviceShare enables HAMi, the global ignored-resource list can start ignoring huawei.com/Ascend310P-memory, but the cached NodeInfo still lacks the device object that should enforce per-device capacity. As a result, the scheduler can log: Devices Ascend310P assertion conversion failed, skip and continue allocating the Pod without calling HAMi FilterNode(). This can bypass physical-device memory validation and allow Ascend memory to be over-accounted. This was observed in a reporter-provided scheduler trace on an Ascend cluster. Evidence and production path The reporter trace in issue #5828 shows this order: Before DeviceShare initialization, cache

What is the problem you're trying to solve Volcano's CLOMonitor score is currently below 95: https://clomonitor.io/projects/cncf/volcano Several checks are failing around security, release metadata, and documentation discovery. Some required documents already exist, but may not be detected because the file names or README links do not match CLOMonitor's expected patterns. Describe the solution you'd like Track and fix the failed CLOMonitor checks. Security and release tasks: Add SECURITY-INSIGHTS.yml for the repo. Assigned to @JesseStutler in #5367. Publish SBOM files with Volcano releases. Assigned to @JesseStutler in #5367. Add or link a dependency management policy from SECURITY-INSIGHTS.yml. This should be handled in the community repository together with the other security documents. Blocked: volcano-sh/community#97 is going to add a security team in the community repo, after volcano-sh/community#97 and #5367 merged, we can continue add the dependency management policy in the

What would you like to be added? This was originally proposed by @devzizu at the community meeting on 2026-05-15. I'm filing it as a tracked issue and grouping it with two adjacent improvements I hit while reviewing #5350. Today the queue controller handles hierarchical state (close cascades to children, open is rejected if the parent is closed), but the admission webhook does not enforce any of these constraints. As a result: Asynchronous controller reconciles race with anything that touches a hierarchical queue, including E2E cleanup. This is the root cause of the flake fixed in #5350, see #5346. OpenQueue on a child whose parent is Closed is only rejected by the controller after retry storms. Deleting an Open queue with foreground propagation hangs until the controller closes it, which is why DeleteQueue in test/e2e/util/queue.go first writes Status.State = Closed. This issue groups three related improvements: 1. Webhook feature flag for cascading child closure (the @devzizu pro