implemented the Preemptable field for podgroup api

[SuyashParmar]

Problem

Current preemptable behavior uses annotations/labels with default false, limiting compatibility.

Solution

Add native Preemptable *bool field to PodGroupSpec:

• nil or true → can be preempted (for compatibility)
• false → cannot be preempted

Changes

• Added field to both API repos (apis/, volcano-apis/)
• Updated scheduler logic to check field first, fall back to annotations
• Regenerated client code

[volcano-sh-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign k82cn
You can assign the PR to them by writing /assign @k82cn in a comment when ready.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[gemini-code-assist]

Summary of Changes

Hello @SuyashParmar, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request primarily focuses on enhancing the PodGroupSpec API by introducing a dedicated Preemptable field. This change aims to provide a more explicit and native mechanism for managing PodGroup preemption, improving clarity and compatibility over previous annotation-based methods. The core of the work involves schema modifications and the necessary regeneration of associated client and conversion code to support this new API field.

Highlights

• API Definition Enhancement: I've introduced a new Preemptable *bool field to the PodGroupSpec in both the core API (pkg/apis/scheduling/types.go) and its v1beta1 version (pkg/apis/scheduling/v1beta1/types.go). This field provides a native way to explicitly control whether a PodGroup can be preempted, moving away from annotation-based behavior. The field's logic is designed for compatibility: nil or true means it can be preempted, while false means it cannot.
• Client and Conversion Code Regeneration: I've updated the auto-generated deepcopy, conversion, and client apply configuration files (zz_generated.deepcopy.go, zz_generated.conversion.go, podgroupspec.go) to correctly handle the new Preemptable field. This ensures proper serialization, deserialization, deep copying, and API version conversions, maintaining compatibility and enabling client-side declarative configuration for the new field.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new Preemptable field to the PodGroupSpec API to provide a native way of controlling preemption, which is a good improvement over using annotations. The changes to the API definitions and the generated client code look mostly correct.

I've identified a significant issue with the protobuf serialization tag for the new field, which could cause interoperability problems. I've left a specific comment with a suggestion to fix it.

Additionally, the pull request description mentions that the scheduler logic was updated to use this new field, but the corresponding code changes are not included in the provided diffs. Please ensure those changes are part of this PR or a subsequent one to complete the feature.

[gemini-code-assist]

The protobuf tag for Preemptable uses bytes, which is incorrect for a boolean type. For protobuf encoding, boolean values should be encoded as varint.

While this might appear to work in some contexts, it's semantically incorrect and can lead to compatibility and serialization issues with other standard Kubernetes tooling or future versions of protobuf.

For reference, standard Kubernetes API types use varint for *bool fields (e.g., core/v1.SecurityContext.AllowPrivilegeEscalation). Using the correct type ensures proper serialization and interoperability.

Please change bytes to varint.

Suggested change

	Preemptable *bool `json:"preemptable,omitempty" protobuf:"bytes,6,opt,name=preemptable"`
	Preemptable *bool `json:"preemptable,omitempty" protobuf:"varint,6,opt,name=preemptable"`

[volcano-sh-bot]

@SuyashParmar: PR needs rebase.

Details

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/test-infra repository.