Repository: kubernetes-sigs/kueue

Issue:
Update KEP-77 with details on batch/v1.Job support for horizontal scaling
<!-- Please only use this template for submitting enhancement requests -->

**What would you like to be added**:

The current version of [KEP-77 – Dynamically Sized Jobs](https://github.com/kubernetes-sigs/kueue/tree/main/keps/77-dynamically-sized-jobs) provides a high-level overview of the motivation and goals for supporting elastic workloads in Kueue but lacks sufficient detail in key implementation areas.

We propose updating the KEP to:

- Emphasize batch/v1.Job as the primary target for initial support of horizontal scaling via WorkloadSlices.
- Provide a more detailed explanation of how scaling is achieved using WorkloadSlices, including:
  - Slice creation, admission, and garbage collection.
  - Scheduling gates for controlling pod execution. 
  - Full-count slice representation instead of delta-based scaling.
  - Slice preemption and admission behavior.
- Clarify the phased rollout plan (single-cluster → multi-cluster).
- Improve consistency with the current controller implementation and inform follow-up design reviews.

**Why is this needed**:

This update will help align the KEP with recent development efforts and provide a clearer path for contributors and reviewers.

**Completion requirements**:

This enhancement requires the following artifacts:

- [x] Design doc
- [ ] API change
- [ ] Docs update

The artifacts should be linked in subsequent comments.


Discussion:
@mimowo: Thank you @ichekrygin for taking the work on the issue. 

Following up on the discussion during wg-batch on June 5th, I think the major design decision is about the scale-up. 

The options I see:
1. the delta workload and merging (as proposed in the initial KEP)
2. the replacement workload which needs to preempt and preemption needs to be explicitly enabled
3. the replacement workload which always preempts the 'stem' workload, even if priority based preemption is disabled. It may or may not preempt other workloads.

Some exploratory questions to guide the design choice:
1. what are the main complications with (1.)? IIUC you decided on (2.) due to some complications. Choosing (2.) allowed to prototype the solution quickly, so I suppose the "replacement workload" has simplicity advantages, but it would be good to summarize them
2. would doing (3.) instead of (2.) increase the complexity significantly? I think it is conceptually cleaner, because in case of (2.) the preemption of the "stem" workload by the "replacement" workload isn't really priority-based. So, I think this is a new kind of "preemption" which does not need to be explicitly enabled. Conceptually slicing could work also when priority-based preemption is disabled (I think). @ichekrygin: I'm currently working on the KEP-77 update PR, and this issue will serve as a tracker for that effort. We can use both this issue and the (upcoming) PR to discuss the content.

My plan is to use this issue to clarify some initial assumptions and address potential misconceptions, then incorporate those refinements into the PR, where we can proceed with a more thorough review.

Does that sound like a good approach?@mimowo: > I'm currently working on the KEP-77 update PR, and this issue will serve as a tracker for that effort. We can use both this issue and the (upcoming) PR to discuss the content.

awesome

> My plan is to use this issue to clarify some initial assumptions and address potential misconceptions

yes, there might have been some gaps in the initial "delta" proposal which make this really hard.

> Does that sound like a good approach?

sgtm@ichekrygin: > 2\. the replacement workload which needs to preempt and preemption needs to be explicitly enabled

To follow up on the requirement for explicit preemption enablement—could you please point me to the specific feature or mechanism you're referring to?
I came across the MultiplePreemptions feature gate, but I'm not sure if that's the one you had in mind.

Update...

After reviewing the issue linked in the GoDoc for MultiplePreemptions, I don't believe this is the correct feature. It doesn’t appear to be a general preemption enablement mechanism, but rather addresses coordination of multiple workload preemptions—specifically in the context of admission decisions involving workloads from different ClusterQueues.

Does that interpretation align with your understanding?@mimowo: I assumed (without looking at your PR yet) only based on the wg-batch discussion, that you require preemption enabled at CQ-level, like [here](https://kueue.sigs.k8s.io/docs/concepts/cluster_queue/#preemption), for example setting `preemption. withinClusterQueue: LowerPriority`, and setting higher priority for the replacement workload. 
@ichekrygin: I think I now understand what you meant by "explicitly enabled preemption."

In the context of Workload Slices, we do not rely on the ClusterQueue's preemption configuration (e.g., withinClusterQueue) to drive preemption decisions. Instead, the preemption target (i.e., the old workload slice) is explicitly added to the preempted workload list during scheduling, regardless of the final flavor assignment mode.

To clarify:

- The preemption of the old workload slice is not a result of the ClusterQueue's generatePreemptionTargets logic.
- The flavor assignment is computed using adjusted capacity requirements, taking into account that the old slice will be preempted and its resources reclaimed.

I've attempted to document this behavior in the implementation. Please take a look and let me know if the documentation is unclear or needs refinement.
Relevant code: [scheduler.go#L501](https://github.com/ichekrygin/kueue/blob/wl-slices/pkg/scheduler/scheduler.go#L501)

In summary, I don’t believe the current workload slice preemption implementation requires any additional, explicit ClusterQueue preemption enablement.
@ichekrygin: > 2. the replacement workload which needs to preempt and preemption needs to be explicitly enabled
> 3. the replacement workload which always preempts the 'stem' workload, even if priority based preemption is disabled. It may or may not preempt other workloads.

I believe bullets 2 and 3 are closely related, in the sense that they do not require explicit preemption enablement via the Kueue `ClusterQueue` configuration (or any other setting).

To elaborate on how WorkloadSlice preemption works, here is a high-level decision tree describing how the scheduler handles flavor assignment and preemption:

1. The scheduler attempts to compute a flavor assignment mode for a given workload against a given `ClusterQueue` capacity.
  - In the context of workload slices, this flavor assignment is based on pod count only (ignoring other resources for simplicity in this discussion).
2. The result of this flavor assignment can be one of the following modes:
  - `"NoFit"`: the workload’s requirements exceed the available capacity.
  - `"Fit"`: the workload fits within the available capacity.
  - `"Preempt"`: the workload could fit if some existing workloads are preempted (evicted).

When computing the flavor assignment for a WorkloadSlice, the scheduler uses an adjusted pod count:
`adjusted_pods = new_slice.pods - old_slice.pods`.
This adjustment reflects that the old slice will be preempted as part of the scheduling process. Crucially, this preemption is guaranteed and happens independently of the ClusterQueue preemption mechanism.

Here is how the scheduler handles the different modes:

- "NoFit":
Even with the old slice preempted, the new slice still doesn't fit.
→ No scheduling action is taken; the new slice remains Pending.
- "Fit":
The new slice fits within the capacity after accounting for the old slice preemption.
→ The scheduler proceeds to admit the new slice.
- "Preempt":
The new slice fits only if additional workloads are preempted.
→ This relies on ClusterQueue-level preemption being enabled, and on the availability of suitable preemption targets.
If either is missing, the new slice stays Pending.

So, to summarize:
- The preemption of the old workload slice is mandatory and does not depend on the ClusterQueue’s preemption configuration.
- Preempting other workloads (in addition to the old slice) requires:
  - ClusterQueue-level preemption to be explicitly enabled, and
  - Suitable preemption targets to be available.
  - Failure to meet these requirements (due to disabled preemption or lack of targets) will result in the new workload slice not being admitted—this is handled by the current Kueue scheduler logic, and the workload remains in the Pending state.@ichekrygin: > 1. the delta workload and merging (as proposed in the initial KEP)

### New Workload Slice: Delta vs. Full
Key differences:

- **Delta**: The new workload slice contains the **additional** pod count required for a scale-up event (i.e., the difference from the current state).
- **Full**: The new workload slice contains the entire **desired** pod count after the scale-up.

After evaluating both options, my assessment is that the Full model offers significant advantages over Delta, for the following reasons:

- The _Full_ model follows a declarative pattern that aligns well with Kubernetes’ declarative API style. A close analogy is how a **new ReplicaSet** represents the full desired replica count, rather than a delta from previous ReplicaSets.
- As a result, the _Full_ model greatly simplifies the processing of the new workload slice. It limits changes to internal logic by reusing Kueue’s existing scaled placement primitives, specifically in the **adjusted flavor assignment** computation.
- In the _Full_ model, the preempted (old) workload slice is deactivated and marked as finished, and the new workload slice takes its place—**no additional cleanup or merging steps are required**.
- In contrast, the _Delta_ model introduces complexity: the new workload slice represents only a partial state, and would likely require a third transformation step to resolve the final state—e.g., `old + delta → final`.

Finally, if the end goal is to produce a final workload state that reflects the desired pod count, then both `old + delta → final` and `old → final` serve the same purpose. The distinction between them is effectively an implementation detail, and the Full model achieves this more cleanly.

I would love to hear your thoughts on this.@mimowo: > After evaluating both options, my assessment is that the Full model offers significant advantages over Delta, for the following reasons:

@ichekrygin thank you for the clear outline of the arguments. I think I agree with them. Especially I can see the complication with ensuring `old + delta → final` is "atomic".

That said, would you also like to think about using the ["second pass" of scheduler](https://github.com/kubernetes-sigs/kueue/blob/2b0c22bdeb9ea3d46842820f0d7b46be412a576e/pkg/workload/workload.go#L651C9-L669) for that? This is a new mechanism we now use for ProvisioningRequest+TAS, and node replacement for TAS, which conceptually fits very close to what we need here. 

IMO this would be an cleaner model as it would be scoped to a single Workload, which already owns the pods. 

For example we could have `status.scalingRequest`  inside the Workload, which would trigger the second pass of scheduler. As a result the new assignment would be built and replaced the old one. This was we can also guarantee the "replacement" workload is assigned to the same flavor, as we already have similar code for TAS: https://github.com/kubernetes-sigs/kueue/blob/main/pkg/scheduler/flavorassigner/flavorassigner.go#L426-L441.@ichekrygin: > would you also like to think about using the ["second pass" of scheduler](https://github.com/kubernetes-sigs/kueue/blob/2b0c22bdeb9ea3d46842820f0d7b46be412a576e/pkg/workload/workload.go#L651C9-L669)

Thanks for the follow-up, @mimowo — and good point about the second pass.

I’ve been looking at [KEP-2724](https://github.com/kubernetes-sigs/kueue/tree/2b0c22bdeb9ea3d46842820f0d7b46be412a576e/keps/2724-topology-aware-scheduling) as the main reference for **TAS**, and I think it’s useful to call out that while there are some surface-level similarities between **TAS** and **WorkloadSlices** (like how **TAS** uses pod scheduling gates for PodSet assignment), I see them addressing pretty different goals overall.

From the perspective of **WorkloadSlices**:

* **WorkloadSlices** apply to all workloads, regardless of whether **TAS** is enabled. That means users can scale up any workload (TAS or not), and the mechanism works the same. It’s really just a general way to express incremental resource needs when a workload scales up.
* Because of that, I’m not sure the "second pass" mechanism adds much value for **WorkloadSlices**. Once a slice is admitted, it typically doesn’t need to go through additional topology checks, unless the workload is TAS-enabled, in which case TAS already handles that logic.
* If we *did* try to tie WorkloadSlices into the second pass flow, we’d run into a few problems. One of the big ones is that a failed admission in the second pass could lead to full workload eviction. That seems less than ideal, especially if we’re just talking about a scale-up. In that case, we’d probably want to keep the original slice running and let the new one sit pending instead.
* There’s also a more nuanced TAS-specific case to consider: imagine a workload that gets admitted fine at first, but then a scale-up slice fails because of topology constraints. What should happen? Do we leave the new slice pending, or do we evict the whole workload? That kind of situation makes me think it’d be useful to let users explicitly define their preferred behavior when a scale-up slice can’t be scheduled.

So, in short: **TAS** "second pass" and **WorkloadSlices** are related in some ways, but I wouldn't say we would benefit from using "second pass" scheduling in **WorkloadSlices** per se. If anything, it probably makes sense to keep **WorkloadSlice** scheduling as close as possible to existing workload handling, regardless of whether **TAS** is in the picture.

Let me know if I’ve misunderstood the intent behind the "second pass" here, or if you see it solving something I’ve missed. Happy to keep the conversation going.
@mimowo: Hi @ichekrygin thanks for the summary. Yes, currently "second pass" is only used for TAS, but I think conceptually it isn't really that coupled and we could say `TopologAwareScheduling=true || resizeRequest`. 

This is a new mechanism so I appreciate there might still be some bugs or gaps. For example, the deactivation after some limit of retries could be easily made dependent on the reason for triggering the second pass, so I'm not concerned here.

Let me ask some exploratory questions:
1. how do you make sure the resized PodSet of the replacement Workload has the same flavor assigned?
2. Do you allow that we would choose another flavor if the old one does not fit the resized workload?

The "second pass" respects the flavor choice. 

Another small benefit of the second pass, is that the "resizeRequest" would be inside the Workload.status, so the relaxation of validation might be conditional.@ichekrygin: Thanks for the clarification @mimowo.

> Yes, currently "second pass" is only used for TAS, but I think conceptually it isn't really that coupled and we could say `TopologAwareScheduling=true || resizeRequest`.

Let me try to recap the “second pass” scheduling mechanism—primarily to confirm my understanding:

1. **First pass (initial admission):** This is the standard workload admission step, as used in traditional "one-pass" scheduling. However, for certain workloads (e.g., those with topology constraints), this step alone may not be sufficient, since Kueue cannot guarantee that pod placement will respect the desired topology.
2. **Second pass:** To address this, Kueue introduces a second phase in which it waits for all pods in the admitted workload to be scheduled *and* to meet the placement constraints (e.g., those defined via TAS). This validation may take one or more iterations.
3. **Successful completion:** If all pods are scheduled within the placement constraints before a timeout or retry threshold, the workload is considered fully admitted, completing the scheduling process.
4. **Failure case:** If pod scheduling fails to satisfy the constraints within the threshold, the workload is considered to have failed scheduling and is evicted.

A key point here is that scheduling is performed at the granularity of the entire workload—i.e., it's all-or-nothing. A critical requirement for entering the "second pass" phase is that the workload has already passed the initial **admission step**, meaning the necessary capacity has been successfully reserved. The second pass is then focused on validating that pod placement satisfies any additional constraints, such as those specified by TAS.

Now, if I understand the direction of this conversation correctly, there's interest in potentially using the “second pass” mechanism to handle *scale-up* requests for already admitted workloads. That’s an interesting idea, though there are a few nuances worth highlighting.

First, while a workload may support `WorkloadSlice`, there’s no guarantee it will be scaled up during its lifetime. But assuming a scale-up *does* occur, the flow might look something like this:

1. A scale-up request is issued for a running workload. The implementation detail is still TBD, but let’s assume we have a mechanism (e.g., `status.conditions` or similar) to communicate the updated desired pod count.  (There may be some concerns around tracking updates—particularly scaling—through the status subresource of a single object, but we can address those separately.)
2. Although the workload is already admitted and running, it re-enters a scheduling state under "second pass" processing to request additional capacity.
3. The scheduler processes the updated workload as a **second pass**, treating the original admission and placement as the **first pass**. In this model, the newly requested capacity is evaluated within the context of an already running workload. The scheduler re-evaluates the workload with the updated pod count, effectively extending the scheduling process without resetting the original admission state.

The key distinction here is that in traditional TAS-style second-pass scheduling, the workload has already been fully admitted and the system is simply enforcing placement constraints. In contrast, for a `WorkloadSlice`-based scale-up, the additional portion of the workload has not yet been admitted—it is still in the process of requesting quota.

If we pursue this direction, we may need to broaden the conceptual and implementation boundaries of the “second pass” to cover workloads that are already running but seeking additional capacity. (Do not confuse this state with "partial admission" since this term already has a specific meaning in Kueue.) Clarifying these semantics will likely require adjustments to how we define admission state and second-pass behavior within Kueue.

If I understand the "second pass" scheduling concept correctly, it addresses a distinctly different problem. Specifically, the WorkloadSlice scale-up case involves a request for a new (additional) capacity, which falls squarely within the domain of the first pass—i.e., traditional Kueue scheduling. There’s a strong argument to be made for keeping the responsibilities of the two passes clearly separated: the first pass is responsible for obtaining and reserving capacity, while the second pass is responsible for validating additional scheduling constraints (such as placement, affinity, or topology). From this perspective, the WorkloadSlice scale-up does not fit into the “additional constraint” category handled by the second pass, but rather represents a new admission request that should go through the standard capacity reservation logic of the first pass.

Please let me know if I’ve correctly understood the concept of "second pass" scheduling, or if there are any issues or gaps in my reasoning.@ichekrygin: > 1. how do you make sure the resized PodSet of the replacement Workload has the same flavor assigned?

This is an excellent observation—thank you for calling it out.

The current `WorkloadSlice` implementation does **not** restrict replacement slices to use the same flavor as the original. In other words, the scheduler will assign *any available* flavor when admitting the replacement. As a result, a single workload may span multiple flavors, which could be problematic in some scenarios—or potentially beneficial in others.

This highlights the need for more refined control over flavor assignment in `WorkloadSlices`. One possible direction is to introduce a concept of **"flavor affinity"**, inspired by Kubernetes’ existing affinity conventions—e.g., `Preferred` vs. `Required`.

I consider this a valuable enhancement that could be addressed in a future phase. That said, please let me know if you view consistent flavor assignment as a **hard requirement**@mimowo: Excellent summary, thank you for elaborating so precisely what alle the nuances. I'm convinced we are on the same page in terms of understanding the mechanics of second pass.

> In contrast, for a WorkloadSlice-based scale-up, the additional portion of the workload has not yet been admitted—it is still in the process of requesting quota.

Very good point indicating the conceptual difference - yes second pass so far does not request quota but only tweaks TAS assignment.

> If we pursue this direction, we may need to broaden the conceptual and implementation boundaries of the “second pass” to cover workloads that are already running but seeking additional capacity. 

Yes, I agree it could be confusing if we start to broaden the term second pass to all request more quota.

However, Im still not clear if there could exist a separate similar mechanism like 'resize pass' just so that we could operate within the realm of a single wlWrokload rather than two. What is simpler in this model is making sure everything is atomic.

To give you one more potential issue with two workloads:
- how do you transfer and sync the state of other status fields such as requeueState tracking the number of evictions due to WaitForPodsReady

Let me alsl return to the question about using the same or different flavor. When you scale a PodSet, do you enforce the same flavor, if so, how to achieve it.

I think the above two problems become easier ib the single Workload model, but I agree, at the expense of complicating scheduler to do the "resize pass".

EDIT: The 'second pass' is still very fresh and nothing is written in stone. if we introduce resize pass, then we could rename 'second pass' as 'tas pass', or 'post quota pass'.@mimowo: > I consider this a valuable enhancement that could be addressed in a future phase. That said, please let me know if you view consistent flavor assignment as a hard requirement

It is definetly not a hard requirement for the first iteration of the feature. This was more exploratory to see how hard / easy it is in both models of the separate WrokloadSlice vs. another resize pass. Since the information lives in a separate object it feels intrinsically more involving to add this enhancement.@mimowo: One more question /scenario regarding the different flavors handling. 

Say we have a Job using old flavor with quota 5cpu, then we resize to use additional 5cpu quota but from new flavor. Now a pod still running on the old flavor fails, so it is replaced, but will WorkloadSlice schedule it on the new flavor or the old flavor? On the new you don't have quota, but for the old I'm not sure how you would know to inject old selectors. 

It seems not an easy problem, I would expect resize either stays in the old flavor, or migrates fully to the new, rather than running partially in both.@ichekrygin: > It seems not an easy problem

Indeed, this is not an easy problem.

In my initial implementation of KEP-77, I did not consider overlapping resource flavors and (incorrectly) assumed that flavor definitions were mutually exclusive. Upon learning that flavors can in fact overlap, I expected Kueue would track their shared resource utilization accordingly. However, it appears that Kueue currently treats overlapping resource flavors as independent, non-overlapping capacities.

This creates a potential (or even actual) issue. For example, if two flavors are defined identically and fully overlap, Kueue will treat them as separate resources. As a result, it may admit workloads into both, effectively doubling the perceived available capacity. This could lead to overcommitment and workloads getting stuck in a `Pending` state once the real underlying capacity is exhausted.

This behavior is what prompted my recent question in Slack ([https://kubernetes.slack.com/archives/C032ZE66A2X/p1749595150273899](https://kubernetes.slack.com/archives/C032ZE66A2X/p1749595150273899)) regarding the relationship between ClusterQueue resource flavor quota tracking and Kubernetes’ native ResourceQuota.

As a Kueue user, I would expect to be able to define ClusterQueue quotas that prevent overprovisioning and ensure predictable scheduling behavior. However, with overlapping resource flavors, this appears to be unachievable in the current model, given the reasons outlined above.

---

With this understanding, I need to revise my implementation for assigning resource flavors to `WorkloadSlice`s. The current draft imposes no restrictions on flavor selection, which can lead to incorrect capacity accounting—particularly in the presence of overlapping resource flavors.

As a first step, a practical improvement would be to restrict `WorkloadSlice` admission to the flavor(s) already assigned to the original workload. That is, we continue admitting slices into the previously assigned flavor if capacity allows. If not, the slice remains in a `Pending` state due to lack of capacity.

If a user wants to scale up into a different flavor (e.g., if the current flavor is exhausted and new capacity is available elsewhere), they would need to delete and re-create the job to trigger a new scheduling decision that considers the updated flavor availability.

While this approach is admittedly sub-optimal in the broader scheme—especially in terms of user experience and flexibility—it may serve as a reasonable first step until Kueue gains support for more intelligent overlapping-flavor accounting and rebalancing.


Let me know if you want to make it more assertive, exploratory, or align it more tightly with SIG/WG discussions.
@mimowo: > In my initial implementation of KEP-77, I did not consider overlapping resource flavors and (incorrectly) assumed that flavor definitions were mutually exclusive.

Actually, I didn't assume overlapping flavors. I think overlapping flavors is a corner case we don't need to take into account for now. Let's consider fully non-overlapping flavors for now.

So, let's say you have two flavors (non-overlapping):
1. reservation (5cpu)
2. on-demand (autoscaled) (10cpu)

Now, you have a workload running on reservation , 5 pods. Now you want to resize it to 10pods, so "on-demand" flavor is used in the replacement Workload. As long as we delete the Pods in the old flavor (reservation) I think this is fine.

If we don't delete the old pods running on the "reservation", then we would keep running Pods outside of our quota assignment. This is not very good, because it may block scheduling another workload which would get quota for reservation.@ichekrygin: >Now, you have a workload running on reservation , 5 pods. Now you want to resize it to 10pods, so "on-demand" flavor is used in the replacement Workload. As long as we delete the Pods in the old flavor (reservation) I think this is fine.
---
With the proposed restriction on flavor assignment for `WorkloadSlice`s—i.e., continuing to use the original flavor—the behavior would still be consistent with the current model. In this case, the new `WorkloadSlice` created during scale-up would simply remain in the `Pending` state if no additional capacity is available in the originally assigned flavor. It would not attempt to switch to another flavor, thereby avoiding issues with quota misaccounting.

As a possible enhancement, we could treat this situation as an eviction trigger. Specifically, if the scale-up cannot be accommodated in the original flavor, it may signal the need for a full workload restart (i.e., delete and recreate the workload) similar to how Kueue currently handles replacement workloads without slices. This would enable re-evaluation of flavor assignments from scratch, allowing the new pods to be scheduled on a different flavor with available capacity.
@ichekrygin: > Actually, I didn't assume overlapping flavors

In my mind, I was treating "overlapping flavors" and a workload qualifying for multiple flavors as the same issue—but you're right, these are distinct cases.@ichekrygin: >If we don't delete the old pods running on the "reservation", then we would keep running Pods outside of our quota assignment. This is not very good, because it may block scheduling another workload which would get quota for reservation.

The key idea behind workload slices is to avoid interrupting workloads whenever possible. However, we're now identifying scenarios—such as resource flavor reassignment during scale-up—where such interruption may be unavoidable.

This issue becomes even more nuanced when dealing with multiple `PodSet`s assigned to different flavors. In such cases, some `PodSet`s may require flavor reassignment to accommodate scale-up, while others may not.

There seem to be two straightforward options for handling this:

* **Treat flavor reassignment as an evictable event**, following the current Kueue model for handling workload updates. This would allow the workload to be torn down and recreated with a new flavor assignment.

* **Disallow flavor reassignment altogether**, in which case the new `WorkloadSlice` would remain in a `Pending` state if the original flavor lacks capacity—similar to how Kueue currently handles out-of-capacity situations.

Selective pod migration between flavors is certainly a more advanced feature. Realistically, Kueue may not have enough contextual data or policy input to determine whether such disruption is desirable from the workload's perspective. If we decide to support this behavior, perhaps it could be governed by a user-specified policy—e.g., a `DisruptionDueToFlavorReassignment` flag—to explicitly allow or disallow flavor migration during scale-up.

What are your thoughts on this direction?

@ichekrygin: In my opinion, **disallowing flavor reassignment altogether** is the safest approach and aligns best with the "principle of least surprise." It ensures that a user's workload—or individual pods within it—will not be torn down and recreated in response to a scale-up event.

This behavior closely mirrors how `Deployment` scaling works in Kubernetes: new pods may fail to schedule due to insufficient capacity, but existing pods are not affected or deleted as a result. Maintaining this predictability in the face of scale-up makes the system easier to reason about and reduces the risk of unintended disruption.

@mimowo: Thank you. We are on the same page. I think `Treat flavor reassignment as an evictable event` and `disallowing flavor reassignment altogether` are both sensible defaults for Alpha version of the feature. 

However, I'm just thinking it might be harder to achieve any of them in the WorkloadSlice approach, because then you need to do lookup between two workloads. 
@mimowo: Finally, there is multiKueue in the picture. I think the WorkloadSlice-based approach may be trickier to make work than the new `status,resizeRequest` field. Let me summarize the status of my considerations in a table.@ichekrygin: > However, I'm just thinking it might be harder to achieve any of them in the WorkloadSlice approach, because then you need to do lookup between two workloads.

It appears that we can retrieve the flavor assignment from the preemptable WorkloadSlice (via WorkloadInfo), as shown here:

![Image](https://github.com/user-attachments/assets/9053911c-596f-46ee-8218-f40c5c067cfd)

With that in mind, we could restrict all future flavor assignments to those already used by the existing workload. If there’s a mismatch, we could potentially treat it as an eviction trigger.

https://github.com/kubernetes-sigs/kueue/blob/489e0a6f15ee585ad74419362a465d432136283f/pkg/scheduler/scheduler.go#L504@ichekrygin: > Finally, there is multiKueue in the picture. I think the WorkloadSlice-based approach may be trickier to make work than the new `status,resizeRequest` field. Let me summarize the status of my considerations in a table.

I completely agree—multiKueue introduces additional complexity to the WorkloadSlice model, particularly with the added dimension of maintaining consistent placement across remote clusters. Fortunately, this complexity is isolated to the multiKueue workload controller and does not propagate into the core workload scheduler logic.@ichekrygin: > the new `status,resizeRequest`

I believe I have a few clarification questions about this feature, but I’m hesitant to raise them here in order to keep the conversation focused on the topic of WorkloadSlice. 

Is there a separate GitHub issue/pr dedicated to `status,resizeRequest` ?
@mimowo: > Is there a separate GitHub issue/pr dedicated to `status,resizeRequest` ?

No, we don't have it. It is just another technical means to achieve issue 77 I'm thinking about.@ichekrygin: Got it, thanks for clarifying.

It would be a good idea to capture this as a standalone issue and link it to KEP-77. That would help frame it either as an alternative approach or a potential prerequisite, depending on where consensus lands. Happy to help review or contribute once the issue is opened.@mimowo: Possibly, I can try to capture this in more details indeed. 

I know this is not formally written down. I could do that, but probably after June 22. So, here is for now just a quick snapshot of different considerations aspects I have:

Complexity & requirements:
| Feature support                          | WorkloadSlice | WorkloadResize | Needed for alpha                                   | Needed for beta |
| --------------------------------- | ------------- | -------------- | -------------------------------------------------- | --------------- |
| MultiKueue support                | medium        | easy           | No                                                 | no              |
| Enforcing resize within flavor    | medium        | easy           | No (but it will be tricky to recommend without it) | Yes             |
| Resizing multiple PodSets at once | high          | medium         |      No                                              |       No          |
| WaitForPodsRrady                  | medium        | for free       | No                                                 | No              |


| Other aspects                          | WorkloadSlice                                                                               | WorkloadResize |
| -------------------------------------- | ------------------------------------------------------------------------------------------- | -------------- |
| Validation                             | relaxed                                                                                     | can be strict  |
| Metrics interpretation                 | Misleading, e.g. Workloads count may show double. Preemption metrics might be confusing too | clear          |
| Complexity of state management changes | high                                                                                        | medium         |
| Complexity of scheduling changes       | medium                                                                                      | high           |
| Atomicity                              | No                                                                                          | Yes            |


So, in this picture, I don't see `WorkloadSlice` being blocked as Alpha solution, but I think there are a couple of serious problems to graduate it as long term solution. So, we could start with it, and either improve, or replace by "WorkloadResize" as the other idea matures.@ichekrygin: > I know this is not formally written down.

Yeah, it's a bit hard to comment meaningfully without a better understanding of what WorkloadResize actually is. Looking forward to the write-up with more details!
@ichekrygin: An early proof-of-concept demonstrating *"sticky"* resource flavor enforcement in action.

### Concept:

Once a workload is admitted using a specific resource flavor, it will retain (or "stick to") that flavor for all future scale-up events—even if this results in failure to admit due to insufficient capacity in that flavor. This enforcement occurs regardless of whether sufficient capacity exists in *other* flavors that could otherwise satisfy the request.

![Image](https://github.com/user-attachments/assets/f7fd0fad-42a6-4d77-b60f-7dc490ed52e8)

### In the screenshot above:

We observe a `ClusterQueue` with two defined resource flavors:

```yaml
- name: default-flavor
  resources:
  - name: cpu
    nominalQuota: 1
  - name: memory
    nominalQuota: 36Gi
- name: vanilla-flavor
  resources:
  - name: cpu
    nominalQuota: 1500m
  - name: memory
    nominalQuota: 36Gi
```

* An initial workload (`demo-slice`) was admitted with a request for 1 pod using `[cpu: 100m, memory: 200Mi]`, and was placed on the `default-flavor`.
* The job was then scaled to 11 pods, resulting in the creation of a new `WorkloadSlice`.
* This new slice failed to be admitted due to insufficient quota in the previously assigned flavor (`default-flavor`), despite the availability of sufficient capacity in the alternative `vanilla-flavor`.

### Admission failure condition:

```yaml
- lastTransitionTime: "2025-06-12T21:32:56Z"
  message: "couldn't assign flavors to pod set main: couldn't change flavor from: default-flavor to: vanilla-flavor, insufficient quota for cpu in flavor default-flavor, request > maximum capacity (1100m > 1)"
  observedGeneration: 1
  reason: Pending
  status: "False"
  type: QuotaReserved
```

### Key takeaway:

Even though `vanilla-flavor` has sufficient capacity to admit the scaled-up workload, admission fails due to the enforced flavor affinity. The workload is not allowed to switch from `default-flavor` to `vanilla-flavor`, illustrating the effect of sticky flavor assignment.

@tenzen-y: /reopen@k8s-ci-robot: @tenzen-y: Reopened this issue.

<details>

In response to [this](https://github.com/kubernetes-sigs/kueue/issues/5527#issuecomment-3103920133):

>/reopen


Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
</details>@tenzen-y: Closing as the implmentations and KEP has already been merged to main branch.

/close@k8s-ci-robot: @tenzen-y: Closing this issue.

<details>

In response to [this](https://github.com/kubernetes-sigs/kueue/issues/5527#issuecomment-3140569712):

>Closing as the implmentations and KEP has already been merged to main branch.
>
>/close


Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
</details>

Solution patch:
diff --git a/charts/kueue/templates/prometheus/monitor.yaml b/charts/kueue/templates/prometheus/monitor.yaml
index b9ad05e83..5f1444fb5 100644
--- a/charts/kueue/templates/prometheus/monitor.yaml
+++ b/charts/kueue/templates/prometheus/monitor.yaml
@@ -17,5 +17,6 @@ spec:
       port: https
       scheme: https
       bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
-      tlsConfig: '{{- toYaml .Values.metrics.serviceMonitor.tlsConfig | nindent 6 }}'
+      tlsConfig:
+      {{- toYaml .Values.metrics.serviceMonitor.tlsConfig | nindent 8 }}
 {{- end }}
diff --git a/cmd/kueueviz/frontend/package-lock.json b/cmd/kueueviz/frontend/package-lock.json
index 4ddb7013d..923c62e9f 100644
--- a/cmd/kueueviz/frontend/package-lock.json
+++ b/cmd/kueueviz/frontend/package-lock.json
@@ -15,13 +15,13 @@
         "@mui/material": "^7.2.0",
         "react": "^19.1.0",
         "react-dom": "^19.0.0",
-        "react-router-dom": "^7.6.3",
+        "react-router-dom": "^7.7.0",
         "react-toastify": "^11.0.5"
       },
       "devDependencies": {
-        "@vitejs/plugin-react": "^4.6.0",
+        "@vitejs/plugin-react": "^4.7.0",
         "depcheck": "^1.4.7",
-        "vite": "^7.0.4"
+        "vite": "^7.0.5"
       }
     },
     "node_modules/@ampproject/remapping": {
@@ -63,22 +63,22 @@
       }
     },
     "node_modules/@babel/core": {
-      "version": "7.27.4",
-      "resolved": "https://registry.npmjs.org/@babel/core/-/core-7.27.4.tgz",
-      "integrity": "sha512-bXYxrXFubeYdvB0NhD/NBB3Qi6aZeV20GOWVI47t2dkecCEoneR4NPVcb7abpXDEvejgrUfFtG6vG/zxAKmg+g==",
+      "version": "7.28.0",
+      "resolved": "https://registry.npmjs.org/@babel/core/-/core-7.28.0.tgz",
+      "integrity": "sha512-UlLAnTPrFdNGoFtbSXwcGFQBtQZJCNjaN6hQNP3UPvuNXT1i82N26KL3dZeIpNalWywr9IuQuncaAfUaS1g6sQ==",
       "dev": true,
       "license": "MIT",
       "dependencies": {
         "@ampproject/remapping": "^2.2.0",
         "@babel/code-frame": "^7.27.1",
-        "@babel/generator": "^7.27.3",
+        "@babel/generator": "^7.28.0",
         "@babel/helper-compilation-targets": "^7.27.2",
         "@babel/helper-module-transforms": "^7.27.3",
-        "@babel/helpers": "^7.27.4",
-        "@babel/parser": "^7.27.4",
+        "@babel/helpers": "^7.27.6",
+        "@babel/parser": "^7.28.0",
         "@babel/template": "^7.27.2",
-        "@babel/traverse": "^7.27.4",
-        "@babel/types": "^7.27.3",
+        "@babel/traverse": "^7.28.0",
+        "@babel/types": "^7.28.0",
         "convert-source-map": "^2.0.0",
         "debug": "^4.1.0",
         "gensync": "^1.0.0-beta.2",
@@ -101,15 +101,15 @@
       "license": "MIT"
     },
     "node_modules/@babel/generator": {
-      "version": "7.27.5",
-      "resolved": "https://registry.npmjs.org/@babel/generator/-/generator-7.27.5.tgz",
-      "integrity": "sha512-ZGhA37l0e/g2s1Cnzdix0O3aLYm66eF8aufiVteOgnwxgnRP8GoyMj7VWsgWnQbVKXyge7hqrFh2K2TQM6t1Hw==",
+      "version": "7.28.0",
+      "resolved": "https://registry.npmjs.org/@babel/generator/-/generator-7.28.0.tgz",
+      "integrity": "sha512-lJjzvrbEeWrhB4P3QBsH7tey117PjLZnDbLiQEKjQ/fNJTjuq4HSqgFA+UNSwZT8D7dxxbnuSBMsa1lrWzKlQg==",
       "license": "MIT",
       "dependencies": {
-        "@babel/parser": "^7.27.5",
-        "@babel/types": "^7.27.3",
-        "@jridgewell/gen-mapping": "^0.3.5",
-        "@jridgewell/trace-mapping": "^0.3.25",
+        "@babel/parser": "^7.28.0",
+        "@babel/types": "^7.28.0",
+        "@jridgewell/gen-mapping": "^0.3.12",
+        "@jridgewell/trace-mapping": "^0.3.28",
         "jsesc": "^3.0.2"
       },
       "engines": {
@@ -133,6 +133,15 @@
         "node": ">=6.9.0"
       }
     },
+    "node_modules/@babel/helper-globals": {
+      "version": "7.28.0",
+      "resolved": "https://registry.npmjs.org/@babel/helper-globals/-/helper-globals-7.28.0.tgz",
+      "integrity": "sha512-+W6cISkXFa1jXsDEdYA8HeevQT/FULhxzR99pxphltZcVaugps53THCeiWA8SguxxpSp3gKPiuYfSWopkLQ4hw==",
+      "license": "MIT",
+      "engines": {
+        "node": ">=6.9.0"
+      }
+    },
     "node_modules/@babel/helper-module-imports": {
       "version": "7.27.1",
       "resolved": "https://registry.npmjs.org/@babel/helper-module-imports/-/helper-module-imports-7.27.1.tgz",
@@ -217,12 +226,12 @@
       }
     },
     "node_modules/@babel/parser": {
-      "version": "7.27.5",
-      "resolved": "https://registry.npmjs.org/@babel/parser/-/parser-7.27.5.tgz",
-      "integrity": "sha512-OsQd175SxWkGlzbny8J3K8TnnDD0N3lrIUtB92xwyRpzaenGZhxDvxN/JgU00U3CDZNj9tPuDJ5H0WS4Nt3vKg==",
+      "version": "7.28.0",
+      "resolved": "https://registry.npmjs.org/@babel/parser/-/parser-7.28.0.tgz",
+      "integrity": "sha512-jVZGvOxOuNSsuQuLRTh13nU0AogFlw32w/MT+LV6D3sP5WdbW61E77RnkbaO2dUvmPAYrBDJXGn5gGS6tH4j8g==",
       "license": "MIT",
       "dependencies": {
-        "@babel/types": "^7.27.3"
+        "@babel/types": "^7.28.0"
       },
       "bin": {
         "parser": "bin/babel-parser.js"
@@ -287,27 +296,27 @@
       }
     },
     "node_modules/@babel/traverse": {
-      "version": "7.27.4",
-      "resolved": "https://registry.npmjs.org/@babel/traverse/-/traverse-7.27.4.tgz",
-      "integrity": "sha512-oNcu2QbHqts9BtOWJosOVJapWjBDSxGCpFvikNR5TGDYDQf3JwpIoMzIKrvfoti93cLfPJEG4tH9SPVeyCGgdA==",
+      "version": "7.28.0",
+      "resolved": "https://registry.npmjs.org/@babel/traverse/-/traverse-7.28.0.tgz",
+      "integrity": "sha512-mGe7UK5wWyh0bKRfupsUchrQGqvDbZDbKJw+kcRGSmdHVYrv+ltd0pnpDTVpiTqnaBru9iEvA8pz8W46v0Amwg==",
       "license": "MIT",
       "dependencies": {
         "@babel/code-frame": "^7.27.1",
-        "@babel/generator": "^7.27.3",
-        "@babel/parser": "^7.27.4",
+        "@babel/generator": "^7.28.0",
+        "@babel/helper-globals": "^7.28.0",
+        "@babel/parser": "^7.28.0",
         "@babel/template": "^7.27.2",
-        "@babel/types": "^7.27.3",
-        "debug": "^4.3.1",
-        "globals": "^11.1.0"
+        "@babel/types": "^7.28.0",
+        "debug": "^4.3.1"
       },
       "engines": {
         "node": ">=6.9.0"
       }
     },
     "node_modules/@babel/types": {
-      "version": "7.27.6",
-      "resolved": "https://registry.npmjs.org/@babel/types/-/types-7.27.6.tgz",
-      "integrity": "sha512-ETyHEk2VHHvl9b9jZP5IHPavHYk57EhanlRRuae9XCpb/j5bDCbPPMOBfCWhnl/7EDJz0jEMCi/RhccCE8r1+Q==",
+      "version": "7.28.1",
+      "resolved": "https://registry.npmjs.org/@babel/types/-/types-7.28.1.tgz",
+      "integrity": "sha512-x0LvFTekgSX+83TI28Y9wYPUfzrnl2aT5+5QLnO6v7mSJYtEEevuDRN0F0uSHRk1G1IWZC43o00Y0xDDrpBGPQ==",
       "license": "MIT",
       "dependencies": {
         "@babel/helper-string-parser": "^7.27.1",
@@ -881,17 +890,13 @@
       }
     },
     "node_modules/@jridgewell/gen-mapping": {
-      "version": "0.3.8",
-      "resolved": "https://registry.npmjs.org/@jridgewell/gen-mapping/-/gen-mapping-0.3.8.tgz",
-      "integrity": "sha512-imAbBGkb+ebQyxKgzv5Hu2nmROxoDOXHh80evxdoXNOrvAnVx7zimzc1Oo5h9RlfV4vPXaE2iM5pOFbvOCClWA==",
+      "version": "0.3.12",
+      "resolved": "https://registry.npmjs.org/@jridgewell/gen-mapping/-/gen-mapping-0.3.12.tgz",
+      "integrity": "sha512-OuLGC46TjB5BbN1dH8JULVVZY4WTdkF7tV9Ys6wLL1rubZnCMstOhNHueU5bLCrnRuDhKPDM4g6sw4Bel5Gzqg==",
       "license": "MIT",
       "dependencies": {
-        "@jridgewell/set-array": "^1.2.1",
-        "@jridgewell/sourcemap-codec": "^1.4.10",
+        "@jridgewell/sourcemap-codec": "^1.5.0",
         "@jridgewell/trace-mapping": "^0.3.24"
-      },
-      "engines": {
-        "node": ">=6.0.0"
       }
     },
     "node_modules/@jridgewell/resolve-uri": {
@@ -903,15 +908,6 @@
         "node": ">=6.0.0"
       }
     },
-    "node_modules/@jridgewell/set-array": {
-      "version": "1.2.1",
-      "resolved": "https://registry.npmjs.org/@jridgewell/set-array/-/set-array-1.2.1.tgz",
-      "integrity": "sha512-R8gLRTZeyp03ymzP/6Lil/28tGeGEzhx1q2k703KGWRAI1VdvPIXdG70VJc2pAMw3NA6JKL5hhFu1sJX0Mnn/A==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=6.0.0"
-      }
-    },
     "node_modules/@jridgewell/sourcemap-codec": {
       "version": "1.5.0",
       "resolved": "https://registry.npmjs.org/@jridgewell/sourcemap-codec/-/sourcemap-codec-1.5.0.tgz",
@@ -919,9 +915,9 @@
       "license": "MIT"
     },
     "node_modules/@jridgewell/trace-mapping": {
-      "version": "0.3.25",
-      "resolved": "https://registry.npmjs.org/@jridgewell/trace-mapping/-/trace-mapping-0.3.25.tgz",
-      "integrity": "sha512-vNk6aEwybGtawWmy/PzwnGDOjCkLWSD2wqvjGGAgOAwCGWySYXfYoxt00IJkTF+8Lb57DwOb3Aa0o9CApepiYQ==",
+      "version": "0.3.29",
+      "resolved": "https://registry.npmjs.org/@jridgewell/trace-mapping/-/trace-mapping-0.3.29.tgz",
+      "integrity": "sha512-uw6guiW/gcAGPDhLmd77/6lW8QLeiV5RUTsAX46Db6oLhGaVj4lhnPwb184s1bkc8kdVg/+h988dro8GRDpmYQ==",
       "license": "MIT",
       "dependencies": {
         "@jridgewell/resolve-uri": "^3.1.0",
@@ -1165,9 +1161,9 @@
       }
     },
     "node_modules/@rolldown/pluginutils": {
-      "version": "1.0.0-beta.19",
-      "resolved": "https://registry.npmjs.org/@rolldown/pluginutils/-/pluginutils-1.0.0-beta.19.tgz",
-      "integrity": "sha512-3FL3mnMbPu0muGOCaKAhhFEYmqv9eTfPSJRJmANrCwtgK8VuxpsZDGK+m0LYAGoyO8+0j5uRe4PeyPDK1yA/hA==",
+      "version": "1.0.0-beta.27",
+      "resolved": "https://registry.npmjs.org/@rolldown/pluginutils/-/pluginutils-1.0.0-beta.27.tgz",
+      "integrity": "sha512-+d0F4MKMCbeVUJwG96uQ4SgAznZNSq93I3V+9NHA4OpvqG8mRCpGdKmK8l/dl02h2CCDHwW2FqilnTyDcAnqjA==",
       "dev": true,
       "license": "MIT"
     },
@@ -1553,16 +1549,16 @@
       }
     },
     "node_modules/@vitejs/plugin-react": {
-      "version": "4.6.0",
-      "resolved": "https://registry.npmjs.org/@vitejs/plugin-react/-/plugin-react-4.6.0.tgz",
-      "integrity": "sha512-5Kgff+m8e2PB+9j51eGHEpn5kUzRKH2Ry0qGoe8ItJg7pqnkPrYPkDQZGgGmTa0EGarHrkjLvOdU3b1fzI8otQ==",
+      "version": "4.7.0",
+      "resolved": "https://registry.npmjs.org/@vitejs/plugin-react/-/plugin-react-4.7.0.tgz",
+      "integrity": "sha512-gUu9hwfWvvEDBBmgtAowQCojwZmJ5mcLn3aufeCsitijs3+f2NsrPtlAWIR6OPiqljl96GVCUbLe0HyqIpVaoA==",
       "dev": true,
       "license": "MIT",
       "dependencies": {
-        "@babel/core": "^7.27.4",
+        "@babel/core": "^7.28.0",
         "@babel/plugin-transform-react-jsx-self": "^7.27.1",
         "@babel/plugin-transform-react-jsx-source": "^7.27.1",
-        "@rolldown/pluginutils": "1.0.0-beta.19",
+        "@rolldown/pluginutils": "1.0.0-beta.27",
         "@types/babel__core": "^7.20.5",
         "react-refresh": "^0.17.0"
       },
@@ -1570,7 +1566,7 @@
         "node": "^14.18.0 || >=16.0.0"
       },
       "peerDependencies": {
-        "vite": "^4.2.0 || ^5.0.0 || ^6.0.0 || ^7.0.0-beta.0"
+        "vite": "^4.2.0 || ^5.0.0 || ^6.0.0 || ^7.0.0"
       }
     },
     "node_modules/@vue/compiler-core": {
@@ -1888,6 +1884,7 @@
       "version": "1.0.2",
       "resolved": "https://registry.npmjs.org/cookie/-/cookie-1.0.2.tgz",
       "integrity": "sha512-9Kr/j4O16ISv8zBBhJoi4bXOYNTkFLOqSL3UDB0njXxCXNezjeyVrJyGOWtgfs/q2km1gwBcfH8q1yEGoMYunA==",
+      "license": "MIT",
       "engines": {
         "node": ">=18"
       }
@@ -2282,15 +2279,6 @@
         "which": "bin/which"
       }
     },
-    "node_modules/globals": {
-      "version": "11.12.0",
-      "resolved": "https://registry.npmjs.org/globals/-/globals-11.12.0.tgz",
-      "integrity": "sha512-WOBp/EEGUiIsJSp7wcv/y6MO+lV9UoncWqxuFfm8eBwzWNgyfBd6Gz+IeKQ9jCmyhoH99g15M3T+QaVHFjizVA==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=4"
-      }
-    },
     "node_modules/hasown": {
       "version": "2.0.2",
       "resolved": "https://registry.npmjs.org/hasown/-/hasown-2.0.2.tgz",
@@ -2824,9 +2812,10 @@
       }
     },
     "node_modules/react-router": {
-      "version": "7.6.3",
-      "resolved": "https://registry.npmjs.org/react-router/-/react-router-7.6.3.tgz",
-      "integrity": "sha512-zf45LZp5skDC6I3jDLXQUu0u26jtuP4lEGbc7BbdyxenBN1vJSTA18czM2D+h5qyMBuMrD+9uB+mU37HIoKGRA==",
+      "version": "7.7.0",
+      "resolved": "https://registry.npmjs.org/react-router/-/react-router-7.7.0.tgz",
+      "integrity": "sha512-3FUYSwlvB/5wRJVTL/aavqHmfUKe0+Xm9MllkYgGo9eDwNdkvwlJGjpPxono1kCycLt6AnDTgjmXvK3/B4QGuw==",
+      "license": "MIT",
       "dependencies": {
         "cookie": "^1.0.1",
         "set-cookie-parser": "^2.6.0"
@@ -2845,11 +2834,12 @@
       }
     },
     "node_modules/react-router-dom": {
-      "version": "7.6.3",
-      "resolved": "https://registry.npmjs.org/react-router-dom/-/react-router-dom-7.6.3.tgz",
-      "integrity": "sha512-DiWJm9qdUAmiJrVWaeJdu4TKu13+iB/8IEi0EW/XgaHCjW/vWGrwzup0GVvaMteuZjKnh5bEvJP/K0MDnzawHw==",
+      "version": "7.7.0",
+      "resolved": "https://registry.npmjs.org/react-router-dom/-/react-router-dom-7.7.0.tgz",
+      "integrity": "sha512-wwGS19VkNBkneVh9/YD0pK3IsjWxQUVMDD6drlG7eJpo1rXBtctBqDyBm/k+oKHRAm1x9XWT3JFC82QI9YOXXA==",
+      "license": "MIT",
       "dependencies": {
-        "react-router": "7.6.3"
+        "react-router": "7.7.0"
       },
       "engines": {
         "node": ">=20.0.0"
@@ -3028,7 +3018,8 @@
     "node_modules/set-cookie-parser": {
       "version": "2.7.1",
       "resolved": "https://registry.npmjs.org/set-cookie-parser/-/set-cookie-parser-2.7.1.tgz",
-      "integrity": "sha512-IOc8uWeOZgnb3ptbCURJWNjWUPcO3ZnTTdzsurqERrP6nPyv+paC55vJM0LpOlT2ne+Ix+9+CRG1MNLlyZ4GjQ=="
+      "integrity": "sha512-IOc8uWeOZgnb3ptbCURJWNjWUPcO3ZnTTdzsurqERrP6nPyv+paC55vJM0LpOlT2ne+Ix+9+CRG1MNLlyZ4GjQ==",
+      "license": "MIT"
     },
     "node_modules/source-map": {
       "version": "0.5.7",
@@ -3200,9 +3191,9 @@
       }
     },
     "node_modules/vite": {
-      "version": "7.0.4",
-      "resolved": "https://registry.npmjs.org/vite/-/vite-7.0.4.tgz",
-      "integrity": "sha512-SkaSguuS7nnmV7mfJ8l81JGBFV7Gvzp8IzgE8A8t23+AxuNX61Q5H1Tpz5efduSN7NHC8nQXD3sKQKZAu5mNEA==",
+      "version": "7.0.5",
+      "resolved": "https://registry.npmjs.org/vite/-/vite-7.0.5.tgz",
+      "integrity": "sha512-1mncVwJxy2C9ThLwz0+2GKZyEXuC3MyWtAAlNftlZZXZDP3AJt5FmwcMit/IGGaNZ8ZOB2BNO/HFUB+CpN0NQw==",
       "dev": true,
       "license": "MIT",
       "dependencies": {
diff --git a/cmd/kueueviz/frontend/package.json b/cmd/kueueviz/frontend/package.json
index db5ae9cb0..da6645a6c 100644
--- a/cmd/kueueviz/frontend/package.json
+++ b/cmd/kueueviz/frontend/package.json
@@ -19,13 +19,13 @@
     "@mui/material": "^7.2.0",
     "react": "^19.1.0",
     "react-dom": "^19.0.0",
-    "react-router-dom": "^7.6.3",
+    "react-router-dom": "^7.7.0",
     "react-toastify": "^11.0.5"
   },
   "devDependencies": {
-    "@vitejs/plugin-react": "^4.6.0",
+    "@vitejs/plugin-react": "^4.7.0",
     "depcheck": "^1.4.7",
-    "vite": "^7.0.4"
+    "vite": "^7.0.5"
   },
   "browserslist": {
     "production": [
diff --git a/go.mod b/go.mod
index a181e52c4..1c59e6944 100644
--- a/go.mod
+++ b/go.mod
@@ -9,7 +9,7 @@ require (
 	github.com/google/go-cmp v0.7.0
 	github.com/json-iterator/go v1.1.12
 	github.com/kubeflow/mpi-operator v0.6.0
-	github.com/kubeflow/training-operator v1.9.2
+	github.com/kubeflow/training-operator v1.9.3
 	github.com/onsi/ginkgo/v2 v2.23.4
 	github.com/onsi/gomega v1.37.0
 	github.com/open-policy-agent/cert-controller v0.13.0
diff --git a/go.sum b/go.sum
index febf5c22d..2905fa7de 100644
--- a/go.sum
+++ b/go.sum
@@ -125,8 +125,8 @@ github.com/kr/text v0.2.0 h1:5Nx0Ya0ZqY2ygV366QzturHI13Jq95ApcVaJBhpS+AY=
 github.com/kr/text v0.2.0/go.mod h1:eLer722TekiGuMkidMxC/pM04lWEeraHUUmBw8l2grE=
 github.com/kubeflow/mpi-operator v0.6.0 h1:RzzG03oyQIiHe/SH2k19N+Hp4QkxEsG2l9G1T7US+ys=
 github.com/kubeflow/mpi-operator v0.6.0/go.mod h1:lu3cj3ESq3SdS29nbHC26TuXiTYYQYTHJ6fcy5Xv20c=
-github.com/kubeflow/training-operator v1.9.2 h1:w5McwkEb7J5QFRo8b8zR9DrgyLHNU2u03Srr9eyLJtc=
-github.com/kubeflow/training-operator v1.9.2/go.mod h1:tkXcAngbhpdskDE75smgfdqOW17tmWJ+2389+FzMNvo=
+github.com/kubeflow/training-operator v1.9.3 h1:aaSHqskOtCY8Dn8sVd+l9p5XAczW6O0nYMPjVLAw/lc=
+github.com/kubeflow/training-operator v1.9.3/go.mod h1:6zI0hgeCOheiW5Z12IcVkKBuSWm714fz8mUvYu4Fid4=
 github.com/kylelemons/godebug v1.1.0 h1:RPNrshWIDI6G2gRW9EHilWtl7Z6Sb1BR0xunSBf0SNc=
 github.com/kylelemons/godebug v1.1.0/go.mod h1:9/0rRGxNHcop5bhtWyNeEfOS8JIWk580+fNqagV/RAw=
 github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de h1:9TO3cAIGXtEhnIaL+V+BEER86oLrvS+kWobKpbJuye0=
diff --git a/hack/processing-plan.yaml b/hack/processing-plan.yaml
index 579d8deb1..703735414 100644
--- a/hack/processing-plan.yaml
+++ b/hack/processing-plan.yaml
@@ -764,9 +764,8 @@ files:
       - type: UPDATE
         key: .metadata.namespace
         value: '"{{ .Release.Namespace }}"'
-      - type: UPDATE
+      - type: DELETE
         key: .spec.endpoints.[].tlsConfig
-        value: '"{{- toYaml .Values.metrics.serviceMonitor.tlsConfig | nindent 6 }}"'
         onFileCondition: '.kind == "ServiceMonitor"'
         onItemCondition: '.spec.endpoints.[].path == "/metrics"'
       - type: UPDATE
@@ -791,6 +790,13 @@ files:
             {{- include "kueue.metricsService.labels" . | nindent 6 }}
         indentation: 2
         onFileCondition: '.kind == "ServiceMonitor"'
+      - type: INSERT_TEXT
+        key: .spec.endpoints.[].bearerTokenFile
+        value: |
+          tlsConfig:
+          {{- toYaml .Values.metrics.serviceMonitor.tlsConfig | nindent 8 }}
+        onFileCondition: '.kind == "ServiceMonitor"'
+        onItemCondition: '.spec.endpoints.[].path == "/metrics"'
       - type: INSERT_TEXT
         position: START
         value: |
diff --git a/keps/77-dynamically-sized-jobs/README.md b/keps/77-dynamically-sized-jobs/README.md
index 0d131a539..760ccde8d 100644
--- a/keps/77-dynamically-sized-jobs/README.md
+++ b/keps/77-dynamically-sized-jobs/README.md
@@ -7,168 +7,331 @@
   - [Non-Goals](#non-goals)
 - [Proposal](#proposal)
   - [User Stories](#user-stories)
-    - [Story 1 - RayCluster w/ autoscaling](#story-1---raycluster-w-autoscaling)
+    - [Story 1 - batchv1/Job scale-down](#story-1---batchv1job-scale-down)
+    - [Story 2 - batchv1/Job scale-up](#story-2---batchv1job-scale-up)
+    - [Story 3 – batch/v1.Job in Multi-Cluster Configuration](#story-3--batchv1job-in-multi-cluster-configuration)
   - [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional)
 - [Design Details](#design-details)
-  - [Workload Slices](#workload-slices)
-  - [Creating Workload Slices](#creating-workload-slices)
+  - [Enablement](#enablement)
+    - [Features](#features)
+    - [WorkloadSliceAnnotation](#workloadsliceannotation)
+  - [Processing of Workload Slices](#processing-of-workload-slices)
+    - [Creation](#creation)
+      - [Naming](#naming)
+    - [Scheduling and Preemption](#scheduling-and-preemption)
+      - [Preemption Disambiguation.](#preemption-disambiguation)
+      - [Resource Flavors](#resource-flavors)
+    - [Garbage Collection of Preempted Workload Slices](#garbage-collection-of-preempted-workload-slices)
   - [Pod Scheduling Gates](#pod-scheduling-gates)
-  - [Garbage Collecting Workload Slices](#garbage-collecting-workload-slices)
+  - [Limitations and Incompatibilities](#limitations-and-incompatibilities)
+    - [PartialAdmission](#partialadmission)
 - [Phases for MVP (alpha)](#phases-for-mvp-alpha)
-  - [Phase 1 - Scale Down](#phase-1---scale-down)
-    - [Job controller](#job-controller)
-  - [Phase 2 - Aggregating Workload Slices](#phase-2---aggregating-workload-slices)
-  - [Phase 3 - Scale up with Workload Slices and Scheduling Gates](#phase-3---scale-up-with-workload-slices-and-scheduling-gates)
-    - [Scheduler](#scheduler)
+  - [Phase 1 - batchv1/Job WorkloadSlices Support in Single-Cluster Configuration.](#phase-1---batchv1job-workloadslices-support-in-single-cluster-configuration)
+    - [Scale Down](#scale-down)
+    - [Scale Up](#scale-up)
+  - [Phase 2 – RayCluster WorkloadSlice Support in Single-Cluster Configuration](#phase-2--raycluster-workloadslice-support-in-single-cluster-configuration)
+  - [Phase 3 – Enabling Workload Slicing for batch/v1.Job in Multi-Cluster Configuration](#phase-3--enabling-workload-slicing-for-batchv1job-in-multi-cluster-configuration)
 - [Additional Details](#additional-details)
   - [Test Plan](#test-plan)
     - [Unit Tests](#unit-tests)
     - [Integration tests](#integration-tests)
+    - [Scale-down](#scale-down-1)
+    - [Scale-Down](#scale-down-2)
+    - [Resource Flavor Handling](#resource-flavor-handling)
   - [Graduation Criteria](#graduation-criteria)
-- [Implementation History](#implementation-history)
-- [Drawbacks](#drawbacks)
+  - [PodScheduling Readiness and ResourceQuota](#podscheduling-readiness-and-resourcequota)
 - [Alternatives](#alternatives)
-  - [Ignore Resize from Kuberay](#ignore-resize-from-kuberay)
 <!-- /toc -->
 
 ## Summary
 
-Enable dynamic sizing of Kueue jobs. For the MVP, we will only focus on supporting RayClusters with autoscaling enabled, but other resources that can benefit from dynamic sizing should be supported eventually.
+Enable dynamic resizing of Kueue-managed workloads by supporting in-place horizontal scaling of job parallelism.
+The primary goal is to allow dynamic adjustment of job parallelism without requiring suspension and requeueing, thereby improving scheduling efficiency and minimizing disruption during resource fluctuations.
 
-See: [Support dynamically sized (elastic) jobs #77](https://github.com/kubernetes-sigs/kueue/issues/77)
+In addition, we aim to extend dynamic resizing support to RayCluster workloads. 
+While the initial focus is on batch/v1.Job and RayCluster, the long-term objective is to generalize support for dynamically sized (elastic) workloads across other Kueue-integrated resource types.
 
 ## Motivation
 
-Kueue currently lacks support for resizing jobs. When a job is resized, Kueue will recreate the Workload representation of the job, leading to a disruptive suspend and requeue process. This limitation hinders the usability of Kueue for resources like RayCluster that sometimes have autoscaling capabilities enabled.
+Kueue currently lacks native support for resizing jobs. Any change in job size leads to the recreation of the associated Workload, resulting in job suspension and requeueing. 
+This disrupts execution and hinders usability for elastic workloads like RayCluster, which rely on in-place autoscaling. 
 
-To properly support RayCluster, Kueue needs to gracefully handle the scale up and scale down of RayCluster nodes. Concretely this means that scaling the resources used by a RayCluster is appropriately reflected in the respective ClusterQueue without needing to suspend the entire RayCluster.
+To support such scenarios, Kueue must gracefully handle horizontal scale-up and scale-down operations without disrupting admitted jobs or re-acquiring quota.
 
 ### Goals
 
-- Gracefully handle resize operations for Kueue jobs (i.e. update quota usage without suspend, enqueue scale ups)
-- Autoscaling RayCluster works with Kueue since it has an autoscaler and there is high demand (MVP)s
-
+- Gracefully handle resize operations for Kueue-managed jobs by updating quota usage without suspending the job or terminating running pods.
+  
 ### Non-Goals
 
-- Vertical scaling of workloads – Kueue will only handle resize operations that scale Pods horizontally 
-- Support resize for other Kueue jobs such as Job, JobSet, etc (future)
-- Resizing of RayJobs
-- Partial Preemption
+- Vertical scaling of workloads – Kueue will only handle resize operations that scale Pods horizontally.
+- Orchestration or initiation of resizing for the parent workload objects (e.g., `batch/v1.Job`, `RayJob`, etc.)
+- Partial Preemption.
 
 ## Proposal
 
 Update the Job framework reconciler and introduce new controllers to orchestrate dynamic resizing of jobs. We are only interested in horizontal scaling of jobs (e.g. scaling more replicas). At a high level, this will be accomplished by:
-- Creating Workload Slice objects that represent incremental scale up of jobs. This gives us per-replica control of workload admission. Workload Slices will be garbage collected and consolidated with their parent workloads after successful admission.
-- Adding default scheduling gates to control the scheduling of new pods based on their admission status.
-- Dynamically adjust quotas in ClusterQueue based on scaling events.
+- Creating WorkloadSlice objects that represent incremental scale up of jobs. This gives us per-replica control of workload admission. Workload Slices will be garbage collected and consolidated with their parent workloads after successful admission.
+  - Adding default scheduling gates to control the scheduling of new pods based on their admission status.
+  - Dynamically adjust quotas in ClusterQueue based on scaling events.
 
-For the MVP, we will only focus on admission of **RayClusters** with autoscaling enabled.
+For the MVP, dynamic resizing will be available through an opt-in mechanism for selected, supported Kueue frameworks—starting with batch/v1.Job and, optionally, RayCluster workloads with autoscaling enabled. 
+Additionally, WorkloadSlice will be supported in the multiKueue context as part of the MVP scope.
 
 ### User Stories
 
-#### Story 1 - RayCluster w/ autoscaling
+#### Story 1 - batchv1/Job scale-down
+
+1. The user creates a `batch/v1.Job` with workload-slice enablement explicitly opted in.
+2. Kueue admits the Job based on its requested resources, creating the corresponding Workload and Job's Pods. The Pods begin running as usual.
+3. The user updates the Job by reducing its parallelism, triggering a scale-down event:
+   1. The associated Workload is updated to reflect the new, lower pod count in its spec. 
+   2. The local queue’s capacity is updated accordingly to reflect the reduced resource usage. 
+   3. One running Job pod is terminated, while the remaining Pods continue running uninterrupted.
+
+#### Story 2 - batchv1/Job scale-up
+1. The user creates a `batch/v1.Job` with workload-slice enablement explicitly opted in.
+2. Kueue admits the Job based on its requested resources, creating the corresponding Workload and Job’s Pods. The Pods begin running as usual.
+3. The user updates the Job by increasing its parallelism, triggering a scale-up event:
+   1. A new WorkloadSlice is created to represent the additional pod capacity requested.
+   2. The new Pods are created in a gated state (via PodSchedulingGates) and held from scheduling until the slice is admitted. 
+   3. Kueue evaluates available resources; if sufficient, the slice is admitted and the scheduling gates on the new Pods are removed. 
+   4. The newly admitted Pods begin scheduling and running, resulting in the Job operating with the increased parallelism level.
 
-1. The user creates a RayCluster with `enableInTreeAutoscaling: true`.
-2. Kueue admits the RayCluster based on the requested resources in the head pod and worker pod. 
-3. Given the demand of the job, the Ray Autoscaler adjusts the replicas field as it adds or removes Pods from the cluster.
-4. Kueue will not suspend and requeue the RayCluster, instead it will dynamically update ClusterQueue usage based on the scaling event. 
+#### Story 3 – batch/v1.Job in Multi-Cluster Configuration
+
+This story mirrors the behaviors in Stories 1 and 2 but applies them within a multi-cluster (MultiKueue) setup, 
+where WorkloadSlices are propagated, admitted, and scheduled across multiple clusters.
 
 ### Notes/Constraints/Caveats (Optional)
 
-If Kueue needs to preempt the resized RayCluster, it would preempt it as a whole, regardless of whether the RayCluster was previously scaled up.
+If Kueue needs to preempt a resized Job, it will preempt the entire Job as a single unit, regardless of whether the Job has undergone a scale-up operation.
 
 ## Design Details
 
-### Workload Slices
-To support horizontal scaling of jobs, we will introduce the concept of a "Workload Slice”. A Workload Slice is a Workload object with an owner reference to the original Workload for a job. Workload Slices represent per-replica changes to a job that were not initially accounted for when the job was created. **It's an internal state, not an extra CRD.**
+To support horizontal scaling of Jobs, we will introduce the concept of a "WorkloadSlice". A WorkloadSlice is a Workload object with an owner reference to the original Workload for a Job. 
+Workload Slices represent per-replica changes to a Job that were not initially accounted for when the Job was created. **It's an internal state, not an extra CRD.**
 
-The benefit of Workload Slices is that Kueue can evaluate admission on a per-replica basis without changing the existing semantics of the Workload API. Once a Workload Slice is admitted, it will be garbage collected and its resources will be aggregated into the admission status of the parent workload.
-- Workload Slices will be submitted to the same LocalQueue that's referenced by the top-level Workload. 
+The benefit of Workload Slices is that Kueue can evaluate admission on a per-replica basis without changing the existing semantics of the Workload API. 
+Once a WorkloadSlice is admitted, it will replace the original/old WorkloadSlice. 
+The replaced slice will be marked as finished.
+- Each WorkloadSlice inherits the resource flavor assignment of the original admitted slice, enforcing flavor consistency across scale-ups. 
 - In MultiKueue, Workload Slices would go into both clusters (management and workload) in a multi-cluster environment.
-- Workload Slices will be created by Kueue and use identical PodTemplates (which is already enforced by Kuberay in the case for RayCluster).
-- Workload Slices will belong to the same resource flavor as the top-level Workload that was initially admitted.
+- Workload Slices will be created by Kueue and use identical PodTemplate.
+- Workload Slices will belong to the same resource flavor as the top-level Workload that was initially admitted (for more details see "Resource Flavors" subsection)
+
 
-The parent Workload should have a condition that reflects the scaling progression status. 
+### Enablement
+
+WorkloadSlices in Kueue are enabled through a combination of a Kubernetes feature gate and an opt-in annotation on individual Workload objects. 
+At the cluster level, the WorkloadSlices feature must be enabled via the corresponding Kueue feature gate, which controls whether the controller logic for slicing is active. 
+
+Once the feature gate is enabled, individual Workload objects can opt into slicing by including the `kueue.x-k8s.io/elastic-job: "true"` annotation. 
+When both conditions are met, Kueue treats the Workload as eligible for partitioning into one or more WorkloadSlice objects, enabling fine-grained scheduling and 
+execution across multiple clusters or within a single cluster. If the feature gate is disabled or the annotation is omitted (or set to "false"), 
+the system defaults to the traditional single-Workload scheduling path for full backward compatibility.
+
+#### Features
+```golang
+// owner: @ichekrygin
+// kep: https://github.com/kubernetes-sigs/kueue/tree/main/keps/77-dynamically-sized-jobs
+//
+// ElasticJobsViaWorkloadSlices enables support for horizontal-scale in jobs.
+ElasticJobsViaWorkloadSlices featuregate.Feature = "ElasticJobsViaWorkloadSlices"
+```
 
+#### WorkloadSliceAnnotation
 ```golang
+// Workload slicing can be enabled for a specific integration job instance,
+// provided that the integration supports workload slicing.
 const (
-  ...
-  ...
-	// WorkloadResizeRequested means that the Workload is in the process of scaling up or down
-	WorkloadResizeRequested = "ResizeRequested"
+  // EnabledAnnotationKey refers to the annotation key present on Job's that support
+  // workload slicing.
+  // This annotation is alpha-level.
+  EnabledAnnotationKey = "kueue.x-k8s.io/elastic-job"
 )
-
 ```
 
-### Creating Workload Slices
+### Processing of Workload Slices
+
+#### Creation
+The creation of WorkloadSlices in Kueue is initiated when a Kueue Job with slicing enabled, via both annotation and feature gate, is admitted for execution. 
+Upon admission, the `jobframework.JobReconciler` evaluates the Job’s PodSets and resource requirements, then creates a new or additional (slice) Workload object 
+that represents a partition of the original workload. Each slice contains a `PodSet.Count` identical to the Job’s definition, along with scheduling metadata needed for handling preemption of the old workload (slice).
+
+At most two active workload slices can exist for any single Job in Kueue: the current admitted slice and a newly created slice during a scaling operation. 
+This ensures a controlled transition between slices while maintaining consistency and avoiding resource contention and race conditions.
 
-The [GenericJob interface (7e778f5)](https://github.com/kubernetes-sigs/kueue/blob/main/pkg/controller/jobframework/interface.go#L30-L55) will be updated to handle resize operations of jobs.
+To facilitate precise resource scheduling and effective workload preemption, every new job configured with slice enablement will be appropriately annotated using `EnabledAnnotationKey/Value` mentioned above.
+Furthermore, each individual workload slice will record the identity of any preempting slice it encounters.
 
 ```golang
-type GenericJob interface {
-  ...
-  ...
-  ResizeJob(wl *kueue.Workload) error
-}
+
+const (
+    // WorkloadSliceReplacementFor is the annotation key used to capture an "old" workload slice key
+    // that will be preempted by the "new", e.g., this workload slice with annotation.
+    WorkloadSliceReplacementFor = "kueue.x-k8s.io/workload-slice-replacement-for"
+)
+```
+
+##### Naming
+Currently, Kueue uses a deterministic Workload naming strategy by generating consistent names for the same Job instance via `GetWorkloadNameForOwnerWithGVK`.
+As a result, Workload names are not unique across different revisions of the same owner object (e.g., a Job), which makes this approach unsuitable for representing Workload slices.
+
+To address this, a new naming strategy will be introduced specifically for Workload slices, incorporating the owner object's generation value to ensure name uniqueness across revisions.
+For example, `bachv1/Job`: 
+```yaml
+annotations:
+  kueue.x-k8s.io/elastic-job: "true"
+creationTimestamp: "2025-06-12T21:32:41Z"
+generation: 1
+labels:
+  kueue.x-k8s.io/queue-name: demo
+name: demo-slice
+namespace: demo
+resourceVersion: "190175"
+uid: 78d1e61a-c399-4c09-800f-a0bbfb5fe71e
+```
+
+will result in a Workload name similar to: `job-demo-slice-75e0c`
+Whereas, changing `generation: 2`: will result in a different name similar to: `job-demo-slice-e7080`
+
+#### Scheduling and Preemption
+Kueue’s scheduler and preemptor components will be augmented to support workload slice processing, specifically by enforcing 
+preemption of the old workload slice regardless of queue capacity to make room for the new slice. 
+
+Scheduling assignment is based on pod count capacity, accounting for the existing workload slice's allocated pods. 
+For example, scaling a job up from `3` pods to `10` pods results in the creation of a new Workload representing all `10` pods; 
+however, the scheduling assignment will reflect only the `7` additional pods needed to admit the new slice, since `3` pods are already accounted for by the existing slice.
+
+While preemption and admission are not strictly atomic operations, they occur within the same scheduling cycle, specifically within the same closure of workload processing. Barring transient errors, for every candidate workload, preemption is immediately followed by admission. We could think of this as quasi-atomic behavior from a scheduling perspective.
+
+What’s important to emphasize is that while the workload object is preempted, the pods associated with the old workload are not. More importantly, those existing pods are effectively absorbed into the new workload.
+
+In the example at hand, preempting an old workload with 3 running pods and admitting a new workload requesting 10 pods (7 of which are pending and schedule-gated), the new workload will effectively consist of 3 running pods and 7 un-gated pods. This transition avoids disruption while maintaining quota integrity.
+
+##### Preemption Disambiguation.
+
+Here, we’re using the term “preemption” to describe the process of replacing an old workload slice with a new one. 
+At the same time, Kueue already uses the concept of workload preemption to mean evicting a workload and deferring its scheduling until capacity becomes available.
+
+In the context of workload slices, it may be more helpful to think of this replacement process as **aggregation** rather than preemption. 
+Aggregation involves terminating the old slice and activating the new one. In the strict sense, neither eviction nor preemption (as traditionally defined) actually occurs during this process.
+
+As such, we mark the old slice with the `Finished` condition. This ensures it is removed from the in-memory ClusterQueue snapshot, and its resource usage is released and attributed to the new slice that replaces it.
+
+A Workload that is preempted by a WorkloadSlice will be correctly marked with a Finished status condition, including an appropriate reason and message.
+```yaml
+- type: Finished
+  status: True
+  reason: WorkloadSliceReplaced
+  message: 'Removed to accommodate a workload (UID: a112b551-a595-4356-875d-e075aee52bac, JobUID: 88d348ca-317a-47a0-bd92-786f95f2608e) due to workload slice aggregation'
+  observedGeneration: 1
+  lastTransitionTime: "2025-07-08T20:09:24Z"
 ```
-Jobs implementing the ResizeJob method will create a Workload Slice for every new replica of a job. 
 
-On scale down to M we will change the original Workload's resources and then on scale up to N we will create N-M WorkloadSlice objects that go through admission and scheduling gate checks, i.e. the Workload can "lose" the original (first time admission) quota when scaling down before scaling up.
+##### Resource Flavors
+
+In the context of WorkloadSlice scheduling, when a workload qualifies for multiple resource flavors, i.e., more than one flavor can satisfy the resource requirements and selector constraints, the scheduler must determine which flavor to assign. 
+Kueue currently does not support combining resources from multiple flavors within a single PodSet; however, multiple PodSets within the same workload may be admitted using different resource flavors.
+
+Flavor selection is influenced by factors such as quota availability, taint tolerations, node label selectors, and, where applicable, topology-aware scheduling policies.
+
+When scaling up a previously admitted workload slice, the current implementation enforces a sticky flavor constraint, meaning that the new slice must reuse the originally assigned flavor, even if other eligible flavors have available capacity. 
+This approach avoids unpredictable flavor switching but may lead to the new slice remaining in a Pending state if the original flavor lacks sufficient resources.
+
+Future enhancements may introduce support for controlled flavor reassignment or user-defined policies to express preferences or tolerances for such transitions.
+
+#### Garbage Collection of Preempted Workload Slices
+Currently, a Workload can become outdated, marked by Kueue as "out-of-sync", and subsequently transitioned to the "Finished" state.
+This also applies to outdated Workload slices: when multiple successive updates are issued for a given Job, any superseded slices are marked as "Finished" to reflect their obsolescence.
+
+Preempted (i.e., aggregated) Workload slices are marked as Finished.
+Under the current design proposal, all finished workload slices are retained indefinitely and are not garbage collected.
+To address potential resource buildup, a `PreemptedWorkloadSliceHistory` mechanism whether as a configuration option or an API field on the Workload, could be introduced to limit the number of retained inactive slices, 
+similar to how `revisionHistoryLimit` is used in Kubernetes Deployments to manage ReplicaSet history.
+
+Preempted Workload slices that fail admission requirements are not marked as Finished, as they were never actually started (i.e., never admitted or executed). 
+
+Similar to current functionality, all Workloads associated with a Job (including slices) will be deleted when the parent Job is removed.
 
 ### Pod Scheduling Gates
 
-Inside the job's webhook, implement schedulingGate injection for pods on creation time.
-The Pods will be ungated following a similar behavior as to how a job is suspended and then unsuspended in the when admitted.
-When the job scales up, the new pods will be gated due to the schedulingGates injection in the webhook.
+Workload slices operate independently of the `spec.suspend` mechanism where applicable, relying instead on pod scheduling gates for admission control. 
+This approach is automatically enabled for supported Job types through defaulting. When a Workload (either initial or a slice) is created, all associated pods are initialized with scheduling gates, effectively "gated" from scheduling. 
+These gates are removed only upon the admission of the corresponding Workload, ensuring controlled and deliberate execution.
+
+```golang
+const (
+...
+  // WorkloadSliceSchedulingGate is the name of the scheduling gate applied to Pods
+  // to delay their scheduling until the associated workload slice has been admitted.
+  // This gate ensures that Pods do not begin scheduling prematurely, maintaining
+  // proper sequencing in workload processing.
+  // This scheduling gate is alpha-level.
+  ElasticJobSchedulingGate = "kueue.x-k8s.io/elastic-job"
+)
+```
 
-After the creation of each individual Workload Slice and admission of a Workload Slice, the **workload_scheduling_gates_controller** should be in charge of removing the scheduling gates from each pod. All worker pods from the same worker group share the same pod template, so we only need to ungate the number of pods to match the number of admitted pods, this should be a counter. We don’t want to accidentally ungate too many pods since race conditions could happen and we also don’t want to double count. It's worth mentioning that for the case of recreated pods (i.e. machine failure for example), these pods will go through the admission/scheduling check again, Kueue is responsible fo removing the scheduling gates when there's available quota and resources to spend on the Job. 
+### Limitations and Incompatibilities
 
-### Garbage Collecting Workload Slices
+This section captures all known limitations and incompatibilities introduced by, or resulting from, enabling the ElasticJobs feature.
 
-The logic of folding and deleting would be isolated in this controller. We don’t necessarily have to say that this Workload Slice belongs to a specific pod. This controller will look at the Workload objects and check whether they have the Admitted condition or not.
+#### PartialAdmission
 
-1. The controller increments the `.status.admission.podSetAssignments.count` and passes the UID of the workload you are folding to the parent workload.
-If we still don’t see the workload being deleted, we at least know it has been counted towards the parent workload and the controller shouldn't fold it again.
+A given Job instance cannot have both `PartialAdmission` and `ElasticJob` enabled. This is a **per-Job limitation**, not a global feature-level conflict. It is entirely valid to have both features enabled in the system, just not simultaneously on the same Job.
 
-## Phases for MVP (alpha)
+**Rationale**
 
-### Phase 1 - Scale Down
-Scaling down will be the first phase towards MVP because it can be implemented without introducing the Workload Slices. 
+* `PartialAdmission` depends on the static nature of a workload. Specifically, it assumes, reasonably, given the current model, that workloads are immutable in terms of `podSets[].count`. Based on this assumption, it adjusts the Job’s spec to reflect the minimum allowed parallelism at scheduling time. This value is fixed and will not change, even if the ClusterQueue’s capacity increases later.
 
-Scaling down a Job won’t involve the creation of Workload Slices, instead it’ll involve an update to the current workload, no requeuing.
+* In practice, `PartialAdmission` takes ownership of `job.spec.parallelism`, and Kueue enforces this immutability through the admission webhook. For example:
 
-1. Compare Pod Counts: Within the job framework, check if the PodSet.Count of the job matches the Workload.Spec.PodSets[1].Count (worker group).
-2. Synchronize Workload: If the pod counts don't match, update the workload to align with the job's PodSet.Count.
-3. Trigger Resource Updates:  By updating the workload in cache and in queue, we'll signal the following:
-- The cluster queue resource usage should recalculate, ensuring accurate resource management.
-- The scheduler should re-evaluate and update PodSetAssignments related to the workload.
+  ```text
+  admission webhook "vjob.kb.io" denied the request: spec.parallelism: Forbidden: cannot change when partial admission is enabled and the job is not suspended
+  ```
 
+**Validation**
 
-#### Job controller
+To avoid delayed or implicit validation errors, any Kueue-integrated Job that supports `ElasticJobs` should include admission validation logic to reject the following annotation combination:
 
-Rework *equivalentToWorkload()* and *reconcile()* to account for potential differences between the job’s number of replicas and the running workload’s PodSet.Count. 
+```yaml
+annotations:
+  kueue.x-k8s.io/dynamically-sized-job: "true"
+  kueue.x-k8s.io/job-min-parallelism: "1"
+```
 
-Given these changes, check if the delta is positive or negative indicating a scaleup/scaledown. If it’s a scaledown the reconciler should trigger an update on the workload to match the new job’s spec and no quota needs to be checked or accounted for, the cluster queue should update the workload resource usage. 
+## Phases for MVP (alpha)
 
-**Important:** in Phase 1 if there's a scale up, the behaviour will be suspend and requeue. This will be temporary while Phase 2 and 3 are not completed.
+### Phase 1 - batchv1/Job WorkloadSlices Support in Single-Cluster Configuration.
 
-### Phase 2 - Aggregating Workload Slices
+Scaling up and down for `batch/v1.Job` will be the initial phase of the MVP, as it builds on stable and well-understood Kubernetes components without requiring additional integration work.
 
-In Phase 2, aggregating Workload Slices into the parent workload will be implemented. This doesn't represent a usable feature to end users, but it can be reviewed independently from the phase 3.
+#### Scale Down
 
-### Phase 3 - Scale up with Workload Slices and Scheduling Gates
+1. Create a Job with workload-slice enablement and a parallelism value greater than 1. 
+2. Observe that a corresponding Workload is created and admitted, and that the Job's pods are in the Running state, matching the specified parallelism. 
+3. Update the Job by reducing its parallelism value. 
+4. Confirm that the existing Workload is updated accordingly, with WorkloadSpec.PodSets[0].Count reflecting the new parallelism value. 
+5. Observe that the number of running pods is reduced, while the remaining pods continue to run uninterrupted.
 
-In Phase 3, scale up will be implemented by introducing Workload Slices and adding Pod scheduling gates as part of Kueue’s mutating admission for the job. 
+#### Scale Up
 
-When a job scales, its webhook would be modified to intercept and "gate" all pods. Every time there’s a resize, you create a dependable (child) workload slice and once it's admitted, you increase the count in the original workload, delete the old workload and remove the schedulingGates. 
-- Pros: You are able to hold the pods added by Kuberay
-- Cons: The fact of having schedulingGates, means we need an API call for every pod, because all pods that are created by the job are going to have schedulingGates. We need to remove those gates and for every pod you need to make API calls.
+1. Create a `batch/v1.Job` with workload-slice enablement and an initial `parallelism` value greater than 0.
+2. Verify that a corresponding `Workload` is created and admitted, and that the Job’s pods are in the `Running` state, matching the specified parallelism.
+3. Increase the Job’s `parallelism` value to trigger a scale-up event.
+4. Confirm that a new `Workload` slice is created and admitted, reflecting the increased pod count, while the previous slice is marked as `Finished`.
+5. Observe that the total number of running pods increases to match the updated parallelism, with the original pods continuing to run without disruption.
 
-#### Scheduler
-Since every scale up will have its own individual workload they should proceed to the current scheduling cycle and continue the normal admission process.
-However, we need to ensure that the Workload Slice is assigned the same resource flavor as the parent workload. 
+### Phase 2 – RayCluster WorkloadSlice Support in Single-Cluster Configuration
+This phase mirrors the steps from Phase 1 but is adapted specifically for RayCluster workloads, taking into account their autoscaling behavior and internal lifecycle management.
 
-The `nominate()` returns the workloads with their requirements (resource flavors, borrowing) if they were admitted by the clusterQueues in the snapshot, so we need to return the original workload that was already admitted with the resize information inside *TotalRequests* so that *PodSetAssignments* is locked to the parent Workload assignments.
+### Phase 3 – Enabling Workload Slicing for batch/v1.Job in Multi-Cluster Configuration
+In this phase, Workload Slicing support for batch/v1.Job will be extended to multi-cluster environments using Kueue’s MultiKueue architecture. 
+When a job is scaled in the management cluster, its corresponding WorkloadSlice will be propagated to the appropriate workload cluster(s), respecting existing cluster assignment and resource flavor constraints. 
+Each WorkloadSlice will be subject to independent admission in the target cluster, and only after successful admission will scheduling gates be lifted to allow pod execution. 
+Slice preemption, quota accounting, and garbage collection must be coordinated across clusters to ensure consistency and avoid orphaned resources. 
+This phase will validate correctness and stability of the slicing mechanism in a federated deployment model.
 
 ## Additional Details
 
@@ -209,18 +372,59 @@ extending the production code to implement this enhancement.
 -->
 The code will adhere to regular best practices for unit tests and coverage.
 
-
-
 #### Integration tests
+
 Integration tests will be executed against mocked clients for Jobs 
 that will provide predefined responses and allow to test various scenarios, 
 including situations like:
 
-* Job has a scale up, workload slices get created, pods are gated
-* Job has a scale up, gated pods are admitted, pods get ungated and assigned same flavors as parent workload
-* Workload slices are correctly folded and deleted
-* Job has a scale down, Workload spec reflects podset count values
-* When Kueue preempt a resized Job, it should preempt it as a whole
+#### Scale-down
+* Job scale down, cluster/local queue correctly reflect resource flavor used capacity.
+
+Here’s a revised and polished version of your text with improved grammar, structure, and clarity:
+
+---
+
+#### Integration Tests
+
+Integration tests will be executed against mocked clients for `batchv1/Job` resources. These mocks will simulate predefined responses, enabling validation of various scheduling and workload slice scenarios, including the following cases:
+
+---
+
+#### Scale-Down
+
+* A `Job` is scaled down.
+* The ClusterQueue and/or local queue correctly reflect the reduced resource usage for the assigned resource flavor.
+
+---
+
+#### Scale-Up
+
+* A `batchv1/Job` is updated to increase its `parallelism` value.
+* New pods are created in the `ScheduleGated` state.
+* A new `WorkloadSlice` is created and admitted.
+* The previous `WorkloadSlice` is marked as "Finished."
+* `ScheduleGates` are removed from the new pods, allowing them to transition to the running state.
+
+---
+
+#### Resource Flavor Handling
+
+* Kueue is configured with two resource flavors, each with different CPU capacities.
+* A `batchv1/Job` is created that matches the selection criteria for both flavors.
+* The job is initially admitted using the flavor with the smaller capacity.
+* The job is later updated to increase `parallelism` beyond the capacity of the originally assigned flavor, but within the capacity of the alternative flavor.
+* New pods are created in the `ScheduleGated` state.
+* The new `WorkloadSlice` remains in a `Pending` state due to the sticky flavor constraint. The status condition resembles the following:
+
+```yaml
+- lastTransitionTime: "2025-06-12T21:32:56Z"
+  message: "couldn't assign flavors to pod set main: couldn't change flavor from: smaller-flavor to: larger-flavor, insufficient quota for cpu in flavor smaller-flavor, request > maximum capacity (1100m > 1)"
+  observedGeneration: 1
+  reason: Pending
+  status: "False"
+  type: QuotaReserved 
+```
 
 ### Graduation Criteria
 <!--
@@ -239,10 +443,54 @@ milestones with these graduation criteria:
 [deprecation-policy]: https://kubernetes.io/docs/reference/using-api/deprecation-policy/
 -->
 
-The feature starts at the alpha level, with a feature gate.
+Here’s a structured and detailed **Graduation Criteria** section for KEP-77: *Dynamically Sized Jobs*, tailored to your current implementation of `WorkloadSlice` and phased MVP plan.
+
+---
 
-In the Alpha version, Dynamically Sized Jobs will support RayCluster resizing. 
-- Scale up/down of replica workers
+### Graduation Criteria
+
+#### Alpha
+
+* [x] Feature is gated by the `ElasticJobsViaWorkloadSlices` feature gate.
+* [x] WorkloadSlice is implemented as an internal Kueue construct (no new CRDs).
+* [x] Scale-up events result in the creation of new `WorkloadSlice`s; scale-downs result in updates to the original `Workload`.
+* [x] Pod-level gating using `PodSchedulingGates` is integrated with slice admission.
+* [x] Sticky flavor behavior is enforced: scale-ups must reuse the original assigned flavor.
+* [x] Superseded slices are marked as `Finished` once the new slice is admitted.
+* [x] Support for `batch/v1.Job` in both single-cluster and multi-cluster (multiKueue) configurations.
+* [x] Integration tests cover basic scale-up, scale-down, and resource flavor constraints.
+* [x] Feature opt-in is supported via workload annotation (`kueue.x-k8s.io/elastic-job: "true"`).
+* [x] Documented enablement steps, slice behavior, and known limitations.
+
+#### Beta
+
+* [ ] Feature is enabled by default in Kueue, still guarded by the feature gate for opt-out.
+* [ ] Complete support for garbage collection of preempted and inactive `WorkloadSlice`s, with tunable retention (e.g., `revisionHistoryLimit`-like mechanism).
+* [ ] Metrics and events emitted for slice lifecycle transitions (e.g., created, admitted, failed admission).
+* [ ] Documentation includes examples for users and integrators to adopt the WorkloadSlice model.
+* [ ] Formal conformance tests validate end-to-end behavior for:
+    * Horizontal scale-up and scale-down
+    * Slice replacements
+    * Sticky flavor enforcement
+    * Multi-cluster propagation
+* [ ] At least one additional framework beyond `batch/v1.Job` (e.g., RayCluster) integrates and validates the WorkloadSlice flow.
+* [ ] Slice lifecycle events (e.g., admitted, preempted, finished) are observable via `kubectl describe workload` or equivalent API tools.
+* [ ] Slice preemption is consistently handled and visible in workload status conditions.
+* [ ] All Kueue core controllers (scheduler, preemptor, queue manager) are validated under slice-enabled workloads.
+* [ ] Dynamic resizing is enabled for all Kueue-managed workloads that support the elastic-job feature (including JobSet, RayJob, Kubeflow jobs, etc.)
+* [ ] Re-evaluate the WorkloadSlice implementation to ensure compatibility with elastic workloads, considering all current and emerging alternatives within Kueue.
+* [ ] Re-evaluate currently disallowed per-job-instance combination of enabled PartialAdmission and ElasticJobs.
+* [ ] Re-evaluate the approach for removing PodSchedulingReadiness gate for admitted workload slices to use a dedicated controller rather than calling from Job reconciler (see 3. in [comment](https://github.com/kubernetes-sigs/kueue/pull/5510#issuecomment-3060737465)).
+
+#### GA (Stable)
+
+* [ ] Proven stability under production-scale workloads, verified through internal deployments or community reports.
+* [ ] Full backwards compatibility: workloads that do not opt into `WorkloadSlice` continue to function identically.
+* [ ] API guarantees around slice naming, preemption markers, and flavor enforcement are documented and stable.
+* [ ] No known correctness issues across single- and multi-cluster environments.
+* [ ] User-configurable policies (optional) for flavor migration or slice aggregation behavior are validated.
+* [ ] Feature is permanently enabled and no longer gated.
+* [ ] Associated documentation, examples, and operational best practices are published as part of the GA release.
 
 
 ## Implementation History
@@ -260,18 +508,40 @@ Major milestones might include:
 
 ## Drawbacks
 
-<!--
-Why should this KEP _not_ be implemented?
--->
+- Adds complexity to Kueue’s scheduling and preemption model.
+- Users must understand new slice lifecycle semantics, which differ from traditional Workload behavior.
+- Leveraging PodSchedulingGates together with ResourceQuota enforcement may result out-of-quota namespaces (see section below for more details).
 
+### ResourceQuota
 
-## Alternatives
+`ResourceQuota` in Kubernetes is a **namespace-scoped object** that limits how much compute, storage, and object-count-based resources a namespace can consume. It is used to enforce fair resource usage in multi-tenant environments and to prevent any single team or workload from consuming excessive cluster resources.
 
+Quota enforcement occurs during the **pod admission phase**. When a pod is created, the API server checks whether the requested resources exceed the available quota in the namespace. If they do, the creation request is rejected.
 
-### Ignore Resize from Kuberay
+`ResourceQuota` includes all pods by default, with a few specific exceptions:
+
+| Pod Type / State         | Counted in Quota? | Notes                                |
+| ------------------------ | ----------------- | ------------------------------------ |
+| Running / Pending Pods   | ✅ Yes             | If they belong to the namespace      |
+| Succeeded / Failed Pods  | ❌ No              | Considered completed and inactive    |
+| Terminating Pods         | ❌ No              | Identified by a `deletionTimestamp`  |
+| Mirror Pods              | ❌ No              | Created directly by the kubelet      |
+| Pods outside quota scope | ❌ No              | If the `ResourceQuota` uses `scopes` |
+
+---
+
+### PodScheduling Readiness and ResourceQuota
+
+**PodScheduling Readiness** is a mechanism that ensures a pod is only eligible for scheduling when it meets specific conditions. This is especially useful for multi-stage scheduling, resource reservation, or coordination with external systems.
+
+An important observation: by default, pods that are gated using `PodSchedulingGates` are still counted toward the namespace's `ResourceQuota` if they do not match any of the exclusion conditions listed above.
+
+As a result, when `PodSchedulingGates` are used in a namespace with quota enforcement, it is possible to exhaust the available quota with ScheduleGated pods that are not yet schedulable. This can block additional pods from being admitted, even though none are actively running.
+
+
+
+## Alternatives
 
-- Idea: Ignoring the scale up or rejecting the scale up from the auto scaler and storing the value in an annotation so that Kueue takes a decision based on the annotation. We’d need a signal from Kueue to hold this in the raycluster_webhook and identify when the resize comes from Kueue, it has to be accepted.
-- Pros: No need to intercept the pods and no need of using schedulingGates
-- Cons: There would be a permanent race bewteen Kueue and Kuberay autoscaler to change the counter in the RayCluster replica number for the worker group. 
-- Exploration: See if autoscaler would indicate a desired size in the spec without altering the number of replicas directly. 
-- Discarded: Higher complexity than gating/ungating pods via SchedulingGates
+- Require users to manage resizing manually by recreating jobs.
+- Defer support for elastic workloads to higher-level controllers (e.g., RayOperator), leaving Kueue unaware of scale operations.
+- [WorkloadResize Request](https://github.com/kubernetes-sigs/kueue/issues/5897) an exploration of an alternative approach to elastic jobs.  
\ No newline at end of file
diff --git a/keps/77-dynamically-sized-jobs/kep.yaml b/keps/77-dynamically-sized-jobs/kep.yaml
index 9c6a69fe3..f965cf918 100644
--- a/keps/77-dynamically-sized-jobs/kep.yaml
+++ b/keps/77-dynamically-sized-jobs/kep.yaml
@@ -2,6 +2,7 @@ title:
 kep-number: 77
 authors:
   - "@vicentefb"
+  - "@ichekrygin"
 status: provisional
 creation-date: 2024-03-14
 reviewers:
@@ -9,15 +10,17 @@ reviewers:
   - "@alculquicondor"
   - "@astefanutti"
   - "@tenzen-y"
+  - "@mimowo"
 approvers:
   - "@alculquicondor"
-
+  - "@mimowo"
+  - "@tenzen-y"
 # The target maturity stage in the current dev cycle for this KEP.
 stage: alpha
 
 # The milestone at which this feature was, or is targeted to be, at each stage.
 milestone:
-  alpha: "v0.8"
+  alpha: "v0.13"
 
 feature-gates:
-  - name: DynamicallySizedJobs
\ No newline at end of file
+  - name: ElasticJobsViaWorkloadSlices
\ No newline at end of file
diff --git a/pkg/cache/cache.go b/pkg/cache/cache.go
index 781947e96..cee124eb9 100644
--- a/pkg/cache/cache.go
+++ b/pkg/cache/cache.go
@@ -59,52 +59,43 @@ const (
 	terminating = metrics.CQStatusTerminating
 )
 
-type options struct {
-	workloadInfoOptions  []workload.InfoOption
-	podsReadyTracking    bool
-	fairSharingEnabled   bool
-	admissionFairSharing *config.AdmissionFairSharing
-}
-
 // Option configures the reconciler.
-type Option func(*options)
+type Option func(*Cache)
 
 // WithPodsReadyTracking indicates the cache controller tracks the PodsReady
 // condition for admitted workloads, and allows to block admission of new
 // workloads until all admitted workloads are in the PodsReady condition.
 func WithPodsReadyTracking(f bool) Option {
-	return func(o *options) {
-		o.podsReadyTracking = f
+	return func(c *Cache) {
+		c.podsReadyTracking = f
 	}
 }
 
 func WithExcludedResourcePrefixes(excludedPrefixes []string) Option {
-	return func(o *options) {
-		o.workloadInfoOptions = append(o.workloadInfoOptions, workload.WithExcludedResourcePrefixes(excludedPrefixes))
+	return func(c *Cache) {
+		c.workloadInfoOptions = append(c.workloadInfoOptions, workload.WithExcludedResourcePrefixes(excludedPrefixes))
 	}
 }
 
 // WithResourceTransformations sets the resource transformations.
 func WithResourceTransformations(transforms []config.ResourceTransformation) Option {
-	return func(o *options) {
-		o.workloadInfoOptions = append(o.workloadInfoOptions, workload.WithResourceTransformations(transforms))
+	return func(c *Cache) {
+		c.workloadInfoOptions = append(c.workloadInfoOptions, workload.WithResourceTransformations(transforms))
 	}
 }
 
 func WithFairSharing(enabled bool) Option {
-	return func(o *options) {
-		o.fairSharingEnabled = enabled
+	return func(c *Cache) {
+		c.fairSharingEnabled = enabled
 	}
 }
 
 func WithAdmissionFairSharing(afs *config.AdmissionFairSharing) Option {
-	return func(o *options) {
-		o.admissionFairSharing = afs
+	return func(c *Cache) {
+		c.admissionFairSharing = afs
 	}
 }
 
-var defaultOptions = options{}
-
 // Cache keeps track of the Workloads that got admitted through ClusterQueues.
 type Cache struct {
 	sync.RWMutex
@@ -124,25 +115,20 @@ type Cache struct {
 	tasCache tasCache
 }
 
-func New(client client.Client, opts ...Option) *Cache {
-	options := defaultOptions
-	for _, opt := range opts {
-		opt(&options)
-	}
-	c := &Cache{
-		client:               client,
-		assumedWorkloads:     make(map[workload.Reference]kueue.ClusterQueueReference),
-		resourceFlavors:      make(map[kueue.ResourceFlavorReference]*kueue.ResourceFlavor),
-		admissionChecks:      make(map[kueue.AdmissionCheckReference]AdmissionCheck),
-		podsReadyTracking:    options.podsReadyTracking,
-		workloadInfoOptions:  options.workloadInfoOptions,
-		fairSharingEnabled:   options.fairSharingEnabled,
-		admissionFairSharing: options.admissionFairSharing,
-		hm:                   hierarchy.NewManager[*clusterQueue, *cohort](newCohort),
-		tasCache:             NewTASCache(client),
-	}
-	c.podsReadyCond.L = &c.RWMutex
-	return c
+func New(client client.Client, options ...Option) *Cache {
+	cache := &Cache{
+		client:           client,
+		assumedWorkloads: make(map[workload.Reference]kueue.ClusterQueueReference),
+		resourceFlavors:  make(map[kueue.ResourceFlavorReference]*kueue.ResourceFlavor),
+		admissionChecks:  make(map[kueue.AdmissionCheckReference]AdmissionCheck),
+		hm:               hierarchy.NewManager[*clusterQueue, *cohort](newCohort),
+		tasCache:         NewTASCache(client),
+	}
+	for _, option := range options {
+		option(cache)
+	}
+	cache.podsReadyCond.L = &cache.RWMutex
+	return cache
 }
 
 func (c *Cache) newClusterQueue(log logr.Logger, cq *kueue.ClusterQueue) (*clusterQueue, error) {
diff --git a/pkg/controller/admissionchecks/multikueue/workload.go b/pkg/controller/admissionchecks/multikueue/workload.go
index 0f8065c34..455901617 100644
--- a/pkg/controller/admissionchecks/multikueue/workload.go
+++ b/pkg/controller/admissionchecks/multikueue/workload.go
@@ -77,19 +77,11 @@ type wlGroup struct {
 	controllerKey types.NamespacedName
 }
 
-type options struct {
-	clock clock.Clock
-}
-
-type Option func(*options)
-
-var defaultOptions = options{
-	clock: realClock,
-}
+type Option func(reconciler *wlReconciler)
 
 func WithClock(_ testing.TB, c clock.Clock) Option {
-	return func(o *options) {
-		o.clock = c
+	return func(r *wlReconciler) {
+		r.clock = c
 	}
 }
 
@@ -471,14 +463,8 @@ func (w *wlReconciler) Generic(_ event.GenericEvent) bool {
 	return true
 }
 
-func newWlReconciler(c client.Client, helper *multiKueueStoreHelper, cRec *clustersReconciler, origin string, recorder record.EventRecorder, workerLostTimeout, eventsBatchPeriod time.Duration, adapters map[string]jobframework.MultiKueueAdapter, opts ...Option) *wlReconciler {
-	options := defaultOptions
-
-	for _, opt := range opts {
-		opt(&options)
-	}
-
-	return &wlReconciler{
+func newWlReconciler(c client.Client, helper *multiKueueStoreHelper, cRec *clustersReconciler, origin string, recorder record.EventRecorder, workerLostTimeout, eventsBatchPeriod time.Duration, adapters map[string]jobframework.MultiKueueAdapter, options ...Option) *wlReconciler {
+	r := &wlReconciler{
 		client:            c,
 		helper:            helper,
 		clusters:          cRec,
@@ -488,8 +474,12 @@ func newWlReconciler(c client.Client, helper *multiKueueStoreHelper, cRec *clust
 		eventsBatchPeriod: eventsBatchPeriod,
 		adapters:          adapters,
 		recorder:          recorder,
-		clock:             options.clock,
+		clock:             realClock,
+	}
+	for _, option := range options {
+		option(r)
 	}
+	return r
 }
 
 func (w *wlReconciler) setupWithManager(mgr ctrl.Manager) error {
diff --git a/pkg/controller/core/workload_controller.go b/pkg/controller/core/workload_controller.go
index 43cc2cd0b..8de6e9d79 100644
--- a/pkg/controller/core/workload_controller.go
+++ b/pkg/controller/core/workload_controller.go
@@ -80,38 +80,30 @@ type workloadRetentionConfig struct {
 	afterFinished *time.Duration
 }
 
-type options struct {
-	watchers                []WorkloadUpdateWatcher
-	waitForPodsReadyConfig  *waitForPodsReadyConfig
-	workloadRetentionConfig *workloadRetentionConfig
-}
-
 // Option configures the reconciler.
-type Option func(*options)
+type Option func(*WorkloadReconciler)
 
 // WithWaitForPodsReady indicates the configuration for the WaitForPodsReady feature.
 func WithWaitForPodsReady(value *waitForPodsReadyConfig) Option {
-	return func(o *options) {
-		o.waitForPodsReadyConfig = value
+	return func(r *WorkloadReconciler) {
+		r.waitForPodsReady = value
 	}
 }
 
 // WithWorkloadUpdateWatchers allows to specify the workload update watchers
 func WithWorkloadUpdateWatchers(value ...WorkloadUpdateWatcher) Option {
-	return func(o *options) {
-		o.watchers = value
+	return func(r *WorkloadReconciler) {
+		r.watchers = value
 	}
 }
 
 // WithWorkloadRetention allows to specify retention for workload resources
 func WithWorkloadRetention(value *workloadRetentionConfig) Option {
-	return func(o *options) {
-		o.workloadRetentionConfig = value
+	return func(r *WorkloadReconciler) {
+		r.workloadRetention = value
 	}
 }
 
-var defaultOptions = options{}
-
 type WorkloadUpdateWatcher interface {
 	NotifyWorkloadUpdate(oldWl, newWl *kueue.Workload)
 }
@@ -132,23 +124,19 @@ type WorkloadReconciler struct {
 var _ reconcile.Reconciler = (*WorkloadReconciler)(nil)
 var _ predicate.TypedPredicate[*kueue.Workload] = (*WorkloadReconciler)(nil)
 
-func NewWorkloadReconciler(client client.Client, queues *queue.Manager, cache *cache.Cache, recorder record.EventRecorder, opts ...Option) *WorkloadReconciler {
-	options := defaultOptions
-	for _, opt := range opts {
-		opt(&options)
+func NewWorkloadReconciler(client client.Client, queues *queue.Manager, cache *cache.Cache, recorder record.EventRecorder, options ...Option) *WorkloadReconciler {
+	r := &WorkloadReconciler{
+		log:      ctrl.Log.WithName("workload-reconciler"),
+		client:   client,
+		queues:   queues,
+		cache:    cache,
+		recorder: recorder,
+		clock:    realClock,
 	}
-
-	return &WorkloadReconciler{
-		log:               ctrl.Log.WithName("workload-reconciler"),
-		client:            client,
-		queues:            queues,
-		cache:             cache,
-		watchers:          options.watchers,
-		waitForPodsReady:  options.waitForPodsReadyConfig,
-		recorder:          recorder,
-		clock:             realClock,
-		workloadRetention: options.workloadRetentionConfig,
+	for _, option := range options {
+		option(r)
 	}
+	return r
 }
 
 // +kubebuilder:rbac:groups="",resources=events,verbs=create;watch;update;patch
diff --git a/pkg/queue/manager.go b/pkg/queue/manager.go
index 8b113157c..bc1abfd42 100644
--- a/pkg/queue/manager.go
+++ b/pkg/queue/manager.go
@@ -46,33 +46,20 @@ var (
 	errClusterQueueAlreadyExists        = errors.New("clusterQueue already exists")
 )
 
-type options struct {
-	podsReadyRequeuingTimestamp config.RequeuingTimestamp
-	workloadInfoOptions         []workload.InfoOption
-	admissionFairSharing        *config.AdmissionFairSharing
-	clock                       clock.WithDelayedExecution
-}
-
 // Option configures the manager.
-type Option func(*options)
-
-var defaultOptions = options{
-	podsReadyRequeuingTimestamp: config.EvictionTimestamp,
-	workloadInfoOptions:         []workload.InfoOption{},
-	clock:                       clock.RealClock{},
-}
+type Option func(*Manager)
 
 // WithClock allows to specify a custom clock
 func WithClock(c clock.WithDelayedExecution) Option {
-	return func(o *options) {
-		o.clock = c
+	return func(m *Manager) {
+		m.clock = c
 	}
 }
 
 func WithAdmissionFairSharing(cfg *config.AdmissionFairSharing) Option {
-	return func(o *options) {
+	return func(m *Manager) {
 		if features.Enabled(features.AdmissionFairSharing) {
-			o.admissionFairSharing = cfg
+			m.admissionFairSharingConfig = cfg
 		}
 	}
 }
@@ -80,22 +67,22 @@ func WithAdmissionFairSharing(cfg *config.AdmissionFairSharing) Option {
 // WithPodsReadyRequeuingTimestamp sets the timestamp that is used for ordering
 // workloads that have been requeued due to the PodsReady condition.
 func WithPodsReadyRequeuingTimestamp(ts config.RequeuingTimestamp) Option {
-	return func(o *options) {
-		o.podsReadyRequeuingTimestamp = ts
+	return func(m *Manager) {
+		m.workloadOrdering.PodsReadyRequeuingTimestamp = ts
 	}
 }
 
 // WithExcludedResourcePrefixes sets the list of excluded resource prefixes
 func WithExcludedResourcePrefixes(excludedPrefixes []string) Option {
-	return func(o *options) {
-		o.workloadInfoOptions = append(o.workloadInfoOptions, workload.WithExcludedResourcePrefixes(excludedPrefixes))
+	return func(m *Manager) {
+		m.workloadInfoOptions = append(m.workloadInfoOptions, workload.WithExcludedResourcePrefixes(excludedPrefixes))
 	}
 }
 
 // WithResourceTransformations sets the resource transformations.
 func WithResourceTransformations(transforms []config.ResourceTransformation) Option {
-	return func(o *options) {
-		o.workloadInfoOptions = append(o.workloadInfoOptions, workload.WithResourceTransformations(transforms))
+	return func(m *Manager) {
+		m.workloadInfoOptions = append(m.workloadInfoOptions, workload.WithResourceTransformations(transforms))
 	}
 }
 
@@ -127,27 +114,25 @@ type Manager struct {
 	secondPassQueue            *secondPassQueue
 }
 
-func NewManager(client client.Client, checker StatusChecker, opts ...Option) *Manager {
-	options := defaultOptions
-	for _, opt := range opts {
-		opt(&options)
-	}
+func NewManager(client client.Client, checker StatusChecker, options ...Option) *Manager {
 	m := &Manager{
-		clock:          options.clock,
+		clock:          realClock,
 		client:         client,
 		statusChecker:  checker,
 		localQueues:    make(map[LocalQueueReference]*LocalQueue),
 		snapshotsMutex: sync.RWMutex{},
 		snapshots:      make(map[kueue.ClusterQueueReference][]kueue.ClusterQueuePendingWorkload, 0),
 		workloadOrdering: workload.Ordering{
-			PodsReadyRequeuingTimestamp: options.podsReadyRequeuingTimestamp,
+			PodsReadyRequeuingTimestamp: config.EvictionTimestamp,
 		},
-		workloadInfoOptions: options.workloadInfoOptions,
+		workloadInfoOptions: []workload.InfoOption{},
 		hm:                  hierarchy.NewManager[*ClusterQueue, *cohort](newCohort),
 
-		topologyUpdateWatchers:     make([]TopologyUpdateWatcher, 0),
-		admissionFairSharingConfig: options.admissionFairSharing,
-		secondPassQueue:            newSecondPassQueue(),
+		topologyUpdateWatchers: make([]TopologyUpdateWatcher, 0),
+		secondPassQueue:        newSecondPassQueue(),
+	}
+	for _, option := range options {
+		option(m)
 	}
 	m.cond.L = &m.RWMutex
 	return m
diff --git a/pkg/util/kubeversion/kubeversion.go b/pkg/util/kubeversion/kubeversion.go
index 172cfd42d..6904f1e08 100644
--- a/pkg/util/kubeversion/kubeversion.go
+++ b/pkg/util/kubeversion/kubeversion.go
@@ -35,24 +35,10 @@ type ServerVersionFetcher struct {
 	rwm           sync.RWMutex
 }
 
-type Options struct {
-	Interval time.Duration
-}
-
-type Option func(*Options)
-
-var defaultOptions = Options{
-	Interval: fetchServerVersionInterval,
-}
-
-func NewServerVersionFetcher(dc discovery.DiscoveryInterface, opts ...Option) *ServerVersionFetcher {
-	options := defaultOptions
-	for _, opt := range opts {
-		opt(&options)
-	}
+func NewServerVersionFetcher(dc discovery.DiscoveryInterface) *ServerVersionFetcher {
 	return &ServerVersionFetcher{
 		dc:            dc,
-		ticker:        time.NewTicker(options.Interval),
+		ticker:        time.NewTicker(fetchServerVersionInterval),
 		serverVersion: &versionutil.Version{},
 	}
 }
diff --git a/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/_index.md b/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/_index.md
index f52902e13..06ceb72df 100644
--- a/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/_index.md
+++ b/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/_index.md
@@ -5,26 +5,21 @@ auto_generated: true
 no_list: true
 ---
 
-<!--
-The file is auto-generated from the Go source code of the component using the
-[generator](https://github.com/kubernetes-sigs/kueue/tree/main/cmd/kueuectl-docs).
--->
+## 概要 {#synopsis}
 
-## Synopsis
 
+创建资源
 
-Create a resource
 
-
-## Examples
+## 示例 {#examples}
 
 ```
-  # Create local queue
+  # 创建本地队列
   kueuectl create localqueue my-local-queue -c my-cluster-queue
 ```
 
 
-## Options
+## 选项 {#options}
 
 
 <table style="width: 100%; table-layout: fixed;">
@@ -39,7 +34,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Must be &#34;none&#34;, &#34;server&#34;, or &#34;client&#34;. If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource.</p>
+            <p>必须是 &#34;none&#34;、&#34;server&#34; 或 &#34;client&#34;。如果是客户端策略，只打印将要发送的对象，而不发送它。如果是服务器策略，提交服务器端请求而不持久化资源。</p>
         </td>
     </tr>
     <tr>
@@ -48,7 +43,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>help for create</p>
+            <p>create 命令的帮助信息</p>
         </td>
     </tr>
     </tbody>
@@ -56,7 +51,7 @@ Create a resource
 
 
 
-## Options inherited from parent commands
+## 从父命令继承的选项 {#options-inherited-from-parent-commands}
 <table style="width: 100%; table-layout: fixed;">
     <colgroup>
         <col span="1" style="width: 10px;" />
@@ -69,7 +64,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Username to impersonate for the operation. User could be a regular user or a service account in a namespace.</p>
+            <p>为操作模拟的用户名。用户可以是常规用户或命名空间中的服务账户。</p>
         </td>
     </tr>
     <tr>
@@ -78,7 +73,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Group to impersonate for the operation, this flag can be repeated to specify multiple groups.</p>
+            <p>为操作模拟的组，此标志可以重复指定多个组。</p>
         </td>
     </tr>
     <tr>
@@ -87,7 +82,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>UID to impersonate for the operation.</p>
+            <p>为操作模拟的 UID。</p>
         </td>
     </tr>
     <tr>
@@ -96,7 +91,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Default cache directory</p>
+            <p>默认缓存目录</p>
         </td>
     </tr>
     <tr>
@@ -105,7 +100,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a cert file for the certificate authority</p>
+            <p>证书颁发机构证书文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -114,7 +109,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a client certificate file for TLS</p>
+            <p>TLS 客户端证书文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -123,7 +118,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a client key file for TLS</p>
+            <p>TLS 客户端密钥文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -132,7 +127,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig cluster to use</p>
+            <p>要使用的 kubeconfig 集群的名称</p>
         </td>
     </tr>
     <tr>
@@ -141,7 +136,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig context to use</p>
+            <p>要使用的 kubeconfig 上下文的名称</p>
         </td>
     </tr>
     <tr>
@@ -150,7 +145,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, opt-out of response compression for all requests to the server</p>
+            <p>如果为 true，则选择退出对所有服务器请求的响应压缩</p>
         </td>
     </tr>
     <tr>
@@ -159,7 +154,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, the server&#39;s certificate will not be checked for validity. This will make your HTTPS connections insecure</p>
+            <p>如果为 true，将不会检查服务器证书的有效性。这将使您的 HTTPS 连接不安全</p>
         </td>
     </tr>
     <tr>
@@ -168,7 +163,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to the kubeconfig file to use for CLI requests.</p>
+            <p>用于 CLI 请求的 kubeconfig 文件的路径。</p>
         </td>
     </tr>
     <tr>
@@ -177,16 +172,16 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If present, the namespace scope for this CLI request</p>
+            <p>如果存在，此 CLI 请求的命名空间范围</p>
         </td>
     </tr>
     <tr>
-        <td colspan="2">--request-timeout string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: &#34;0&#34;</td>
+        <td colspan="2">--request-timeout string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;默认值: &#34;0&#34;</td>
     </tr>
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don&#39;t timeout requests.</p>
+            <p>在放弃单个服务器请求之前等待的时间长度。非零值应包含相应的时间单位（例如 1s、2m、3h）。零值表示不超时请求。</p>
         </td>
     </tr>
     <tr>
@@ -195,7 +190,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The address and port of the Kubernetes API server</p>
+            <p>Kubernetes API 服务器的地址和端口</p>
         </td>
     </tr>
     <tr>
@@ -204,7 +199,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used</p>
+            <p>用于服务器证书验证的服务器名称。如果未提供，则使用用于联系服务器的主机名</p>
         </td>
     </tr>
     <tr>
@@ -213,7 +208,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Bearer token for authentication to the API server</p>
+            <p>用于 API 服务器身份验证的持有者令牌</p>
         </td>
     </tr>
     <tr>
@@ -222,7 +217,7 @@ Create a resource
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig user to use</p>
+            <p>要使用的 kubeconfig 用户的名称</p>
         </td>
     </tr>
     </tbody>
@@ -230,10 +225,10 @@ Create a resource
 
 
 
-## See Also
+## 另请参阅 {#see-also}
 
-* [kueuectl](../kueuectl/)	 - Controls Kueue queueing manager
-* [kueuectl create clusterqueue](kueuectl_create_clusterqueue/)	 - Creates a clusterqueue
-* [kueuectl create localqueue](kueuectl_create_localqueue/)	 - Creates a localqueue
-* [kueuectl create resourceflavor](kueuectl_create_resourceflavor/)	 - Creates a resource flavor
+* [kueuectl](../kueuectl/) - 控制 Kueue 队列管理器
+* [kueuectl create clusterqueue](kueuectl_create_clusterqueue/) - 创建集群队列
+* [kueuectl create localqueue](kueuectl_create_localqueue/) - 创建本地队列
+* [kueuectl create resourceflavor](kueuectl_create_resourceflavor/) - 创建资源类型
 
diff --git a/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_clusterqueue.md b/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_clusterqueue.md
index b7e773399..addd0e969 100644
--- a/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_clusterqueue.md
+++ b/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_clusterqueue.md
@@ -5,28 +5,23 @@ auto_generated: true
 no_list: false
 ---
 
-<!--
-The file is auto-generated from the Go source code of the component using the
-[generator](https://github.com/kubernetes-sigs/kueue/tree/main/cmd/kueuectl-docs).
--->
+## 概要 {#synopsis}
 
-## Synopsis
 
-
-Creates a ClusterQueue with the given name.
+使用给定名称创建 ClusterQueue。
 
 ```
 kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUEUEING_STRATEGY] [--namespace-selector KEY=VALUE] [--reclaim-within-cohort PREEMPTION_POLICY] [--preemption-within-cluster-queue PREEMPTION_POLICY] [--nominal-quota RESOURCE_FLAVOR:RESOURCE=VALUE] [--borrowing-limit RESOURCE_FLAVOR:RESOURCE=VALUE] [--lending-limit RESOURCE_FLAVOR:RESOURCE=VALUE] [--dry-run STRATEGY]
 ```
 
 
-## Examples
+## 示例 {#examples}
 
 ```
-  # Create a ClusterQueue
+  # 创建 ClusterQueue
   kueuectl create clusterqueue my-cluster-queue
   
-  # Create a ClusterQueue with cohort, namespace selector and other details
+  # 创建具有队列组、命名空间选择器和其他详细信息的 ClusterQueue
   kueuectl create clusterqueue my-cluster-queue \
   --cohort cohortname \
   --queuing-strategy StrictFIFO \
@@ -34,10 +29,10 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
   --reclaim-within-cohort Any \
   --preemption-within-cluster-queue LowerPriority
   
-  # Create a ClusterQueue with nominal quota and one resource flavor named alpha
+  # 创建具有标称配额和一个名为 alpha 的资源类型的 ClusterQueue
   kueuectl create clusterqueue my-cluster-queue --nominal-quota "alpha:cpu=9;memory=36Gi"
   
-  # Create a ClusterQueue with multiple resource flavors named alpha and beta
+  # 创建具有多个资源类型（名为 alpha 和 beta）的 ClusterQueue
   kueuectl create clusterqueue my-cluster-queue \
   --cohort cohortname \
   --nominal-quota "alpha:cpu=9;memory=36Gi;nvidia.com/gpu=10,beta:cpu=18;memory=72Gi;nvidia.com/gpu=20" \
@@ -46,7 +41,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
 ```
 
 
-## Options
+## 选项 {#options}
 
 
 <table style="width: 100%; table-layout: fixed;">
@@ -61,7 +56,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.</p>
+            <p>如果为 true，当模板中缺少字段或映射键时忽略模板中的任何错误。仅适用于 golang 和 jsonpath 输出格式。</p>
         </td>
     </tr>
     <tr>
@@ -70,7 +65,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The maximum amount of quota for the [flavor, resource] combination that this ClusterQueue is allowed to borrow from the unused quota of other ClusterQueues in the same cohort.</p>
+            <p>此 ClusterQueue 允许从同一队列组中其他 ClusterQueue 的未使用配额中借用的[类型，资源]组合的最大配额量。</p>
         </td>
     </tr>
     <tr>
@@ -79,7 +74,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The cohort that this ClusterQueue belongs to.</p>
+            <p>此 ClusterQueue 所属的队列组。</p>
         </td>
     </tr>
     <tr>
@@ -88,7 +83,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>help for clusterqueue</p>
+            <p>clusterqueue 的帮助信息</p>
         </td>
     </tr>
     <tr>
@@ -97,7 +92,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The maximum amount of unused quota for the [flavor, resource] combination that this ClusterQueue can lend to other ClusterQueues in the same cohort.</p>
+            <p>此 ClusterQueue 可以借给同一队列组中其他 ClusterQueue 的[类型，资源]组合的未使用配额的最大量。</p>
         </td>
     </tr>
     <tr>
@@ -106,7 +101,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Defines which namespaces are allowed to submit workloads to this clusterQueue.</p>
+            <p>定义允许向此 ClusterQueue 提交工作负载的命名空间。</p>
         </td>
     </tr>
     <tr>
@@ -115,7 +110,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The quantity of this resource that is available for Workloads admitted by this ClusterQueue at a point in time.</p>
+            <p>在某个时间点此 ClusterQueue 接纳的工作负载可用的此资源的数量。</p>
         </td>
     </tr>
     <tr>
@@ -124,7 +119,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).</p>
+            <p>输出格式。可选值为：json、yaml、name、go-template、go-template-file、template、templatefile、jsonpath、jsonpath-as-json、jsonpath-file。</p>
         </td>
     </tr>
     <tr>
@@ -133,7 +128,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Determines whether a pending Workload that doesn&#39;t fit within the nominal quota for its ClusterQueue, can preempt active Workloads in the ClusterQueue.</p>
+            <p>确定不符合其 ClusterQueue 标称配额的待处理工作负载是否可以抢占 ClusterQueue 中的活动工作负载。</p>
         </td>
     </tr>
     <tr>
@@ -142,7 +137,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The queueing strategy of the workloads across the queues in this ClusterQueue.</p>
+            <p>此 ClusterQueue 中队列间工作负载的排队策略。</p>
         </td>
     </tr>
     <tr>
@@ -151,7 +146,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Determines whether a pending Workload can preempt Workloads from other ClusterQueues in the cohort that are using more than their nominal quota.</p>
+            <p>确定待处理工作负载是否可以抢占队列组中使用超过其标称配额的其他 ClusterQueue 中的工作负载。</p>
         </td>
     </tr>
     <tr>
@@ -160,7 +155,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, keep the managedFields when printing objects in JSON or YAML format.</p>
+            <p>如果为 true，在 JSON 或 YAML 格式打印对象时保留 managedFields。</p>
         </td>
     </tr>
     <tr>
@@ -169,7 +164,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].</p>
+            <p>当-o=go-template、-o=go-template-file 时使用的模板字符串或模板文件路径。模板格式是 golang 模板 [http://golang.org/pkg/text/template/#pkg-overview]。</p>
         </td>
     </tr>
     </tbody>
@@ -177,7 +172,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
 
 
 
-## Options inherited from parent commands
+## 从父命令继承的选项 {#options-inherited-from-parent-commands}
 <table style="width: 100%; table-layout: fixed;">
     <colgroup>
         <col span="1" style="width: 10px;" />
@@ -190,7 +185,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Username to impersonate for the operation. User could be a regular user or a service account in a namespace.</p>
+            <p>为操作模拟的用户名。用户可以是常规用户或命名空间中的服务账户。</p>
         </td>
     </tr>
     <tr>
@@ -199,7 +194,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Group to impersonate for the operation, this flag can be repeated to specify multiple groups.</p>
+            <p>为操作模拟的组，此标志可以重复指定多个组。</p>
         </td>
     </tr>
     <tr>
@@ -208,7 +203,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>UID to impersonate for the operation.</p>
+            <p>为操作模拟的 UID。</p>
         </td>
     </tr>
     <tr>
@@ -217,7 +212,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Default cache directory</p>
+            <p>默认缓存目录</p>
         </td>
     </tr>
     <tr>
@@ -226,7 +221,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a cert file for the certificate authority</p>
+            <p>证书颁发机构证书文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -235,7 +230,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a client certificate file for TLS</p>
+            <p>TLS 客户端证书文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -244,7 +239,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a client key file for TLS</p>
+            <p>TLS 客户端密钥文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -253,7 +248,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig cluster to use</p>
+            <p>要使用的 kubeconfig 集群的名称</p>
         </td>
     </tr>
     <tr>
@@ -262,7 +257,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig context to use</p>
+            <p>要使用的 kubeconfig 上下文的名称</p>
         </td>
     </tr>
     <tr>
@@ -271,7 +266,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, opt-out of response compression for all requests to the server</p>
+            <p>如果为 true，则选择退出对所有服务器请求的响应压缩</p>
         </td>
     </tr>
     <tr>
@@ -280,7 +275,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Must be &#34;none&#34;, &#34;server&#34;, or &#34;client&#34;. If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource.</p>
+            <p>必须是 &#34;none&#34;、&#34;server&#34; 或 &#34;client&#34;。如果是客户端策略，只打印将要发送的对象，而不发送它。如果是服务器策略，提交服务器端请求而不持久化资源。</p>
         </td>
     </tr>
     <tr>
@@ -289,7 +284,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, the server&#39;s certificate will not be checked for validity. This will make your HTTPS connections insecure</p>
+            <p>如果为 true，将不会检查服务器证书的有效性。这将使您的 HTTPS 连接不安全</p>
         </td>
     </tr>
     <tr>
@@ -298,7 +293,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to the kubeconfig file to use for CLI requests.</p>
+            <p>用于 CLI 请求的 kubeconfig 文件的路径。</p>
         </td>
     </tr>
     <tr>
@@ -307,7 +302,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If present, the namespace scope for this CLI request</p>
+            <p>如果存在，此 CLI 请求的命名空间范围</p>
         </td>
     </tr>
     <tr>
@@ -316,7 +311,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don&#39;t timeout requests.</p>
+            <p>在放弃单个服务器请求之前等待的时间长度。非零值应包含相应的时间单位（例如 1s、2m、3h）。零值表示不超时请求。</p>
         </td>
     </tr>
     <tr>
@@ -325,7 +320,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The address and port of the Kubernetes API server</p>
+            <p>Kubernetes API 服务器的地址和端口</p>
         </td>
     </tr>
     <tr>
@@ -334,7 +329,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used</p>
+            <p>用于服务器证书验证的服务器名称。如果未提供，则使用用于联系服务器的主机名</p>
         </td>
     </tr>
     <tr>
@@ -343,7 +338,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Bearer token for authentication to the API server</p>
+            <p>用于 API 服务器身份验证的持有者令牌</p>
         </td>
     </tr>
     <tr>
@@ -352,7 +347,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig user to use</p>
+            <p>要使用的 kubeconfig 用户的名称</p>
         </td>
     </tr>
     </tbody>
@@ -360,7 +355,7 @@ kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUE
 
 
 
-## See Also
+## 另请参阅 {#see-also}
 
-* [kueuectl create](../)	 - Create a resource
+* [kueuectl create](../) - 创建资源
 
diff --git a/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_localqueue.md b/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_localqueue.md
index a160b84cf..6073a776a 100644
--- a/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_localqueue.md
+++ b/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_localqueue.md
@@ -5,33 +5,28 @@ auto_generated: true
 no_list: false
 ---
 
-<!--
-The file is auto-generated from the Go source code of the component using the
-[generator](https://github.com/kubernetes-sigs/kueue/tree/main/cmd/kueuectl-docs).
--->
+## 概要 {#synopsis}
 
-## Synopsis
 
-
-Create a local queue with the given name in the specified namespace.
+在指定命名空间中使用给定名称创建本地队列。
 
 ```
 kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--dry-run STRATEGY]
 ```
 
 
-## Examples
+## 示例 {#examples}
 
 ```
-  # Create a local queue
+  # 创建本地队列
   kueuectl create localqueue my-local-queue -c my-cluster-queue
   
-  # Create a local queue with unknown cluster queue
+  # 创建具有未知集群队列的本地队列
   kueuectl create localqueue my-local-queue -c my-cluster-queue -i
 ```
 
 
-## Options
+## 选项 {#options}
 
 
 <table style="width: 100%; table-layout: fixed;">
@@ -46,7 +41,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.</p>
+            <p>如果为 true，当模板中缺少字段或映射键时忽略模板中的任何错误。仅适用于 golang 和 jsonpath 输出格式。</p>
         </td>
     </tr>
     <tr>
@@ -55,7 +50,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The cluster queue name which will be associated with the local queue (required).</p>
+            <p>将与本地队列关联的集群队列名称（必需）。</p>
         </td>
     </tr>
     <tr>
@@ -64,7 +59,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>help for localqueue</p>
+            <p>localqueue 的帮助信息</p>
         </td>
     </tr>
     <tr>
@@ -73,7 +68,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Ignore unknown cluster queue.</p>
+            <p>忽略未知的集群队列。</p>
         </td>
     </tr>
     <tr>
@@ -82,7 +77,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).</p>
+            <p>输出格式。可选值为：json、yaml、name、go-template、go-template-file、template、templatefile、jsonpath、jsonpath-as-json、jsonpath-file。</p>
         </td>
     </tr>
     <tr>
@@ -91,7 +86,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, keep the managedFields when printing objects in JSON or YAML format.</p>
+            <p>如果为 true，在 JSON 或 YAML 格式打印对象时保留 managedFields。</p>
         </td>
     </tr>
     <tr>
@@ -100,7 +95,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].</p>
+            <p>当-o=go-template、-o=go-template-file 时使用的模板字符串或模板文件路径。模板格式是 golang 模板 [http://golang.org/pkg/text/template/#pkg-overview]。</p>
         </td>
     </tr>
     </tbody>
@@ -108,7 +103,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
 
 
 
-## Options inherited from parent commands
+## 从父命令继承的选项 {#options-inherited-from-parent-commands}
 <table style="width: 100%; table-layout: fixed;">
     <colgroup>
         <col span="1" style="width: 10px;" />
@@ -121,7 +116,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Username to impersonate for the operation. User could be a regular user or a service account in a namespace.</p>
+            <p>为操作模拟的用户名。用户可以是常规用户或命名空间中的服务账户。</p>
         </td>
     </tr>
     <tr>
@@ -130,7 +125,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Group to impersonate for the operation, this flag can be repeated to specify multiple groups.</p>
+            <p>为操作模拟的组，此标志可以重复指定多个组。</p>
         </td>
     </tr>
     <tr>
@@ -139,7 +134,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>UID to impersonate for the operation.</p>
+            <p>为操作模拟的 UID。</p>
         </td>
     </tr>
     <tr>
@@ -148,7 +143,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Default cache directory</p>
+            <p>默认缓存目录</p>
         </td>
     </tr>
     <tr>
@@ -157,7 +152,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a cert file for the certificate authority</p>
+            <p>证书颁发机构证书文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -166,7 +161,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a client certificate file for TLS</p>
+            <p>TLS 客户端证书文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -175,7 +170,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a client key file for TLS</p>
+            <p>TLS 客户端密钥文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -184,7 +179,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig cluster to use</p>
+            <p>要使用的 kubeconfig 集群的名称</p>
         </td>
     </tr>
     <tr>
@@ -193,7 +188,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig context to use</p>
+            <p>要使用的 kubeconfig 上下文的名称</p>
         </td>
     </tr>
     <tr>
@@ -202,7 +197,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, opt-out of response compression for all requests to the server</p>
+            <p>如果为 true，则选择退出对所有服务器请求的响应压缩</p>
         </td>
     </tr>
     <tr>
@@ -211,7 +206,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Must be &#34;none&#34;, &#34;server&#34;, or &#34;client&#34;. If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource.</p>
+            <p>必须是 &#34;none&#34;、&#34;server&#34; 或 &#34;client&#34;。如果是客户端策略，只打印将要发送的对象，而不发送它。如果是服务器策略，提交服务器端请求而不持久化资源。</p>
         </td>
     </tr>
     <tr>
@@ -220,7 +215,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, the server&#39;s certificate will not be checked for validity. This will make your HTTPS connections insecure</p>
+            <p>如果为 true，将不会检查服务器证书的有效性。这将使您的 HTTPS 连接不安全</p>
         </td>
     </tr>
     <tr>
@@ -229,7 +224,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to the kubeconfig file to use for CLI requests.</p>
+            <p>用于 CLI 请求的 kubeconfig 文件的路径。</p>
         </td>
     </tr>
     <tr>
@@ -238,7 +233,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If present, the namespace scope for this CLI request</p>
+            <p>如果存在，此 CLI 请求的命名空间范围</p>
         </td>
     </tr>
     <tr>
@@ -247,7 +242,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don&#39;t timeout requests.</p>
+            <p>在放弃单个服务器请求之前等待的时间长度。非零值应包含相应的时间单位（例如 1s、2m、3h）。零值表示不超时请求。</p>
         </td>
     </tr>
     <tr>
@@ -256,7 +251,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The address and port of the Kubernetes API server</p>
+            <p>Kubernetes API 服务器的地址和端口</p>
         </td>
     </tr>
     <tr>
@@ -265,7 +260,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used</p>
+            <p>用于服务器证书验证的服务器名称。如果未提供，则使用用于联系服务器的主机名</p>
         </td>
     </tr>
     <tr>
@@ -274,7 +269,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Bearer token for authentication to the API server</p>
+            <p>用于 API 服务器身份验证的持有者令牌</p>
         </td>
     </tr>
     <tr>
@@ -283,7 +278,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig user to use</p>
+            <p>要使用的 kubeconfig 用户的名称</p>
         </td>
     </tr>
     </tbody>
@@ -291,7 +286,7 @@ kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--d
 
 
 
-## See Also
+## 另请参阅 {#see-also}
 
-* [kueuectl create](../)	 - Create a resource
+* [kueuectl create](../) - 创建资源
 
diff --git a/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_resourceflavor.md b/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_resourceflavor.md
index b219d3db1..d204c295a 100644
--- a/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_resourceflavor.md
+++ b/site/content/zh-CN/docs/reference/kubectl-kueue/commands/kueuectl_create/kueuectl_create_resourceflavor.md
@@ -5,42 +5,37 @@ auto_generated: true
 no_list: false
 ---
 
-<!--
-The file is auto-generated from the Go source code of the component using the
-[generator](https://github.com/kubernetes-sigs/kueue/tree/main/cmd/kueuectl-docs).
--->
+## 概要 {#synopsis}
 
-## Synopsis
 
-
-Create a resource flavor with the given name.
+使用给定名称创建资源类型。
 
 ```
 kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY[=VALUE]:EFFECT] [--tolerations KEY[=VALUE][:EFFECT]]|:EFFECT [--dry-run STRATEGY]
 ```
 
 
-## Examples
+## 示例 {#examples}
 
 ```
-  # Create a resource flavor
+  # 创建资源类型
   kueuectl create resourceflavor my-resource-flavor
   
-  # Create a resource flavor with labels
+  # 创建具有标签的资源类型
   kueuectl create resourceflavor my-resource-flavor \
   --node-labels kubernetes.io/arch=arm64,kubernetes.io/os=linux
   
-  # Create a resource flavor with node taints
+  # 创建具有节点污点的资源类型
   kueuectl create resourceflavor my-resource-flavor \
   --node-taints key1=value:NoSchedule,key2:NoExecute
   
-  # Create a resource flavor with tolerations
+  # 创建具有容忍度的资源类型
   kueuectl create resourceflavor my-resource-flavor \
   --tolerations key1=value:NoSchedule,key2:NoExecute,key3=value,key4,:PreferNoSchedule
 ```
 
 
-## Options
+## 选项 {#options}
 
 
 <table style="width: 100%; table-layout: fixed;">
@@ -55,7 +50,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.</p>
+            <p>如果为 true，当模板中缺少字段或映射键时忽略模板中的任何错误。仅适用于 golang 和 jsonpath 输出格式。</p>
         </td>
     </tr>
     <tr>
@@ -64,7 +59,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>help for resourceflavor</p>
+            <p>ResourceFlavor 的帮助信息</p>
         </td>
     </tr>
     <tr>
@@ -73,7 +68,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Labels that associate the ResourceFlavor with Nodes that have the same labels.</p>
+            <p>将 ResourceFlavor 与具有相同标签的节点关联的标签。</p>
         </td>
     </tr>
     <tr>
@@ -82,7 +77,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Taints that the nodes associated with this ResourceFlavor have.</p>
+            <p>与此 ResourceFlavor 关联的节点所具有的污点。</p>
         </td>
     </tr>
     <tr>
@@ -91,7 +86,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file).</p>
+            <p>输出格式。可选值为：json、yaml、name、go-template、go-template-file、template、templatefile、jsonpath、jsonpath-as-json、jsonpath-file。</p>
         </td>
     </tr>
     <tr>
@@ -100,7 +95,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, keep the managedFields when printing objects in JSON or YAML format.</p>
+            <p>如果为 true，在 JSON 或 YAML 格式打印对象时保留 managedFields。</p>
         </td>
     </tr>
     <tr>
@@ -109,7 +104,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Template string or path to template file to use when -o=go-template, -o=go-template-file. The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview].</p>
+            <p>当-o=go-template、-o=go-template-file 时使用的模板字符串或模板文件路径。模板格式是 golang 模板 [http://golang.org/pkg/text/template/#pkg-overview]。</p>
         </td>
     </tr>
     <tr>
@@ -118,7 +113,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Extra tolerations that will be added to the pods admitted in the quota associated with this resource flavor.</p>
+            <p>将添加到此资源类型关联的配额中接纳的 Pod 的额外容忍度。</p>
         </td>
     </tr>
     </tbody>
@@ -126,7 +121,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
 
 
 
-## Options inherited from parent commands
+## 从父命令继承的选项 {#options-inherited-from-parent-commands}
 <table style="width: 100%; table-layout: fixed;">
     <colgroup>
         <col span="1" style="width: 10px;" />
@@ -139,7 +134,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Username to impersonate for the operation. User could be a regular user or a service account in a namespace.</p>
+            <p>为操作模拟的用户名。用户可以是常规用户或命名空间中的服务账户。</p>
         </td>
     </tr>
     <tr>
@@ -148,7 +143,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Group to impersonate for the operation, this flag can be repeated to specify multiple groups.</p>
+            <p>为操作模拟的组，此标志可以重复指定多个组。</p>
         </td>
     </tr>
     <tr>
@@ -157,7 +152,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>UID to impersonate for the operation.</p>
+            <p>为操作模拟的 UID。</p>
         </td>
     </tr>
     <tr>
@@ -166,7 +161,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Default cache directory</p>
+            <p>默认缓存目录</p>
         </td>
     </tr>
     <tr>
@@ -175,7 +170,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a cert file for the certificate authority</p>
+            <p>证书颁发机构证书文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -184,7 +179,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a client certificate file for TLS</p>
+            <p>TLS 客户端证书文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -193,7 +188,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to a client key file for TLS</p>
+            <p>TLS 客户端密钥文件的路径</p>
         </td>
     </tr>
     <tr>
@@ -202,7 +197,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig cluster to use</p>
+            <p>要使用的 kubeconfig 集群的名称</p>
         </td>
     </tr>
     <tr>
@@ -211,7 +206,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig context to use</p>
+            <p>要使用的 kubeconfig 上下文的名称</p>
         </td>
     </tr>
     <tr>
@@ -220,7 +215,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, opt-out of response compression for all requests to the server</p>
+            <p>如果为 true，则选择退出对所有服务器请求的响应压缩</p>
         </td>
     </tr>
     <tr>
@@ -229,7 +224,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Must be &#34;none&#34;, &#34;server&#34;, or &#34;client&#34;. If client strategy, only print the object that would be sent, without sending it. If server strategy, submit server-side request without persisting the resource.</p>
+            <p>必须是 &#34;none&#34;、&#34;server&#34; 或 &#34;client&#34;。如果是客户端策略，只打印将要发送的对象，而不发送它。如果是服务器策略，提交服务器端请求而不持久化资源。</p>
         </td>
     </tr>
     <tr>
@@ -238,7 +233,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If true, the server&#39;s certificate will not be checked for validity. This will make your HTTPS connections insecure</p>
+            <p>如果为 true，将不会检查服务器证书的有效性。这将使您的 HTTPS 连接不安全</p>
         </td>
     </tr>
     <tr>
@@ -247,7 +242,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Path to the kubeconfig file to use for CLI requests.</p>
+            <p>用于 CLI 请求的 kubeconfig 文件的路径。</p>
         </td>
     </tr>
     <tr>
@@ -256,7 +251,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>If present, the namespace scope for this CLI request</p>
+            <p>如果存在，此 CLI 请求的命名空间范围</p>
         </td>
     </tr>
     <tr>
@@ -265,7 +260,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don&#39;t timeout requests.</p>
+            <p>在放弃单个服务器请求之前等待的时间长度。非零值应包含相应的时间单位（例如 1s、2m、3h）。零值表示不超时请求。</p>
         </td>
     </tr>
     <tr>
@@ -274,7 +269,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The address and port of the Kubernetes API server</p>
+            <p>Kubernetes API 服务器的地址和端口</p>
         </td>
     </tr>
     <tr>
@@ -283,7 +278,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used</p>
+            <p>用于服务器证书验证的服务器名称。如果未提供，则使用用于联系服务器的主机名</p>
         </td>
     </tr>
     <tr>
@@ -292,7 +287,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>Bearer token for authentication to the API server</p>
+            <p>用于 API 服务器身份验证的持有者令牌</p>
         </td>
     </tr>
     <tr>
@@ -301,7 +296,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
     <tr>
         <td></td>
         <td style="line-height: 130%; word-wrap: break-word;">
-            <p>The name of the kubeconfig user to use</p>
+            <p>要使用的 kubeconfig 用户的名称</p>
         </td>
     </tr>
     </tbody>
@@ -309,7 +304,7 @@ kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY
 
 
 
-## See Also
+## 另请参阅 {#see-also}
 
-* [kueuectl create](../)	 - Create a resource
+* [kueuectl create](../) - 创建资源
 
diff --git a/vendor/modules.txt b/vendor/modules.txt
index ea9657ca2..e30fa34c7 100644
--- a/vendor/modules.txt
+++ b/vendor/modules.txt
@@ -188,7 +188,7 @@ github.com/json-iterator/go
 # github.com/kubeflow/mpi-operator v0.6.0
 ## explicit; go 1.23
 github.com/kubeflow/mpi-operator/pkg/apis/kubeflow/v2beta1
-# github.com/kubeflow/training-operator v1.9.2
+# github.com/kubeflow/training-operator v1.9.3
 ## explicit; go 1.23
 github.com/kubeflow/training-operator/pkg/apis/kubeflow.org/v1
 # github.com/kylelemons/godebug v1.1.0



Test patch:
diff --git a/pkg/scheduler/flavorassigner/flavorassigner_test.go b/pkg/scheduler/flavorassigner/flavorassigner_test.go
index e23ca69de..97520d844 100644
--- a/pkg/scheduler/flavorassigner/flavorassigner_test.go
+++ b/pkg/scheduler/flavorassigner/flavorassigner_test.go
@@ -2706,3 +2706,77 @@ func TestHierarchical(t *testing.T) {
 		})
 	}
 }
+
+func TestWorkloadsTopologyRequests_ErrorBranches(t *testing.T) {
+	cases := map[string]struct {
+		cq         cache.ClusterQueueSnapshot
+		assignment Assignment
+		workload   workload.Info
+		wantErr    string
+	}{
+		"workload requires Topology, but there is no TAS cache information": {
+			cq: cache.ClusterQueueSnapshot{
+				TASFlavors: map[kueue.ResourceFlavorReference]*cache.TASFlavorSnapshot{},
+			},
+			assignment: Assignment{
+				PodSets: []PodSetAssignment{{
+					Name: kueue.DefaultPodSetName,
+					Flavors: ResourceAssignment{
+						corev1.ResourceCPU: {Name: "default", Mode: Fit, TriedFlavorIdx: -1},
+					},
+					Count:  1,
+					Status: &Status{},
+				}},
+			},
+			workload: *workload.NewInfo(&kueue.Workload{
+				Spec: kueue.WorkloadSpec{
+					PodSets: []kueue.PodSet{
+						*utiltesting.MakePodSet(kueue.DefaultPodSetName, 1).
+							Request(corev1.ResourceCPU, "1").
+							RequiredTopologyRequest(corev1.LabelHostname).
+							Obj(),
+					},
+				},
+			}),
+			wantErr: "workload requires Topology, but there is no TAS cache information",
+		},
+		"workload requires Topology, but there is no TAS cache information for the assigned flavor": {
+			cq: cache.ClusterQueueSnapshot{
+				TASFlavors: map[kueue.ResourceFlavorReference]*cache.TASFlavorSnapshot{"tas": nil},
+			},
+			assignment: Assignment{
+				PodSets: []PodSetAssignment{{
+					Name: kueue.DefaultPodSetName,
+					Flavors: ResourceAssignment{
+						corev1.ResourceCPU: {Name: "tas", Mode: Fit, TriedFlavorIdx: -1},
+					},
+					Count:  1,
+					Status: &Status{},
+				}},
+			},
+			workload: *workload.NewInfo(&kueue.Workload{
+				Spec: kueue.WorkloadSpec{
+					PodSets: []kueue.PodSet{
+						*utiltesting.MakePodSet(kueue.DefaultPodSetName, 1).
+							Request(corev1.ResourceCPU, "1").
+							RequiredTopologyRequest(corev1.LabelHostname).
+							Obj(),
+					},
+				},
+			}),
+			wantErr: "workload requires Topology, but there is no TAS cache information for the assigned flavor",
+		},
+	}
+
+	for name, tc := range cases {
+		t.Run(name, func(t *testing.T) {
+			tasReqs := tc.assignment.WorkloadsTopologyRequests(&tc.workload, &tc.cq)
+			if len(tasReqs) != 0 {
+				t.Errorf("expected no TAS requests, got: %+v", tasReqs)
+			}
+			if diff := cmp.Diff(tc.wantErr, tc.assignment.PodSets[0].Status.err.Error()); diff != "" {
+				t.Errorf("Error mismatch (-want +got):\n%s", diff)
+			}
+		})
+	}
+}
diff --git a/pkg/scheduler/scheduler_test.go b/pkg/scheduler/scheduler_test.go
index fb855289d..b96da3faf 100644
--- a/pkg/scheduler/scheduler_test.go
+++ b/pkg/scheduler/scheduler_test.go
@@ -1651,43 +1651,39 @@ func TestSchedule(t *testing.T) {
 		"hierarchical fair sharing schedule workload which wins tournament": {
 			enableFairSharing: true,
 			cohorts: []kueue.Cohort{
-				utiltesting.MakeCohort("A").
+				*utiltesting.MakeCohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "200").Obj(),
-					).Cohort,
-				utiltesting.MakeCohort("B").Parent("A").Cohort,
-				utiltesting.MakeCohort("C").Parent("A").Cohort,
+					).Obj(),
+				*utiltesting.MakeCohort("B").Parent("A").Obj(),
+				*utiltesting.MakeCohort("C").Parent("A").Obj(),
 			},
 			additionalClusterQueues: []kueue.ClusterQueue{
-				utiltesting.MakeClusterQueue("d").
+				*utiltesting.MakeClusterQueue("d").
 					Cohort("B").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
-				utiltesting.MakeClusterQueue("e").
+					).Obj(),
+				*utiltesting.MakeClusterQueue("e").
 					Cohort("B").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
-				utiltesting.MakeClusterQueue("f").
+					).Obj(),
+				*utiltesting.MakeClusterQueue("f").
 					Cohort("C").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
-				utiltesting.MakeClusterQueue("g").
+					).Obj(),
+				*utiltesting.MakeClusterQueue("g").
 					Cohort("C").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
+					).Obj(),
 			},
 			additionalLocalQueues: []kueue.LocalQueue{
 				*utiltesting.MakeLocalQueue("lq-d", "eng-alpha").ClusterQueue("d").Obj(),
@@ -1696,51 +1692,51 @@ func TestSchedule(t *testing.T) {
 				*utiltesting.MakeLocalQueue("lq-g", "eng-alpha").ClusterQueue("g").Obj(),
 			},
 			workloads: []kueue.Workload{
-				utiltesting.MakeWorkload("d0", "eng-alpha").
+				*utiltesting.MakeWorkload("d0", "eng-alpha").
 					Queue("lq-d").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "10").
-						PodSet).
+						Obj()).
 					ReserveQuota(utiltesting.MakeAdmission("d", "one").Assignment(corev1.ResourceCPU, "on-demand", "10").Obj()).
-					Workload,
-				utiltesting.MakeWorkload("e0", "eng-alpha").
+					Obj(),
+				*utiltesting.MakeWorkload("e0", "eng-alpha").
 					Queue("lq-e").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "20").
-						PodSet).
+						Obj()).
 					ReserveQuota(utiltesting.MakeAdmission("e", "one").Assignment(corev1.ResourceCPU, "on-demand", "20").Obj()).
-					Workload,
-				utiltesting.MakeWorkload("g0", "eng-alpha").
+					Obj(),
+				*utiltesting.MakeWorkload("g0", "eng-alpha").
 					Queue("lq-g").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "100").
-						PodSet).
+						Obj()).
 					ReserveQuota(utiltesting.MakeAdmission("g", "one").Assignment(corev1.ResourceCPU, "on-demand", "100").Obj()).
-					Workload,
-				utiltesting.MakeWorkload("d1", "eng-alpha").
+					Obj(),
+				*utiltesting.MakeWorkload("d1", "eng-alpha").
 					Queue("lq-d").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "70").
-						PodSet).
-					Workload,
-				utiltesting.MakeWorkload("e1", "eng-alpha").
+						Obj()).
+					Obj(),
+				*utiltesting.MakeWorkload("e1", "eng-alpha").
 					Queue("lq-e").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "61").
-						PodSet).
-					Workload,
-				utiltesting.MakeWorkload("f1", "eng-alpha").
+						Obj()).
+					Obj(),
+				*utiltesting.MakeWorkload("f1", "eng-alpha").
 					Queue("lq-f").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "1").
-						PodSet).
-					Workload,
-				utiltesting.MakeWorkload("g1", "eng-alpha").
+						Obj()).
+					Obj(),
+				*utiltesting.MakeWorkload("g1", "eng-alpha").
 					Queue("lq-g").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "1").
-						PodSet).
-					Workload,
+						Obj()).
+					Obj(),
 			},
 			wantAssignments: map[workload.Reference]kueue.Admission{
 				"eng-alpha/d0": *utiltesting.MakeAdmission("d", "one").Assignment(corev1.ResourceCPU, "on-demand", "10").Obj(),
@@ -1763,52 +1759,50 @@ func TestSchedule(t *testing.T) {
 		"fair sharing schedule workload with lowest drf after admission": {
 			enableFairSharing: true,
 			cohorts: []kueue.Cohort{
-				utiltesting.MakeCohort("A").
+				*utiltesting.MakeCohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "100").Obj(),
-					).Cohort,
+					).Obj(),
 			},
 			additionalClusterQueues: []kueue.ClusterQueue{
-				utiltesting.MakeClusterQueue("b").
+				*utiltesting.MakeClusterQueue("b").
 					Cohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
-				utiltesting.MakeClusterQueue("c").
+					).Obj(),
+				*utiltesting.MakeClusterQueue("c").
 					Cohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
+					).Obj(),
 			},
 			additionalLocalQueues: []kueue.LocalQueue{
 				*utiltesting.MakeLocalQueue("lq-b", "eng-alpha").ClusterQueue("b").Obj(),
 				*utiltesting.MakeLocalQueue("lq-c", "eng-alpha").ClusterQueue("c").Obj(),
 			},
 			workloads: []kueue.Workload{
-				utiltesting.MakeWorkload("b0", "eng-alpha").
+				*utiltesting.MakeWorkload("b0", "eng-alpha").
 					Queue("lq-b").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "10").
-						PodSet).
+						Obj()).
 					ReserveQuota(utiltesting.MakeAdmission("b", "one").Assignment(corev1.ResourceCPU, "on-demand", "10").Obj()).
-					Workload,
-				utiltesting.MakeWorkload("b1", "eng-alpha").
+					Obj(),
+				*utiltesting.MakeWorkload("b1", "eng-alpha").
 					Queue("lq-b").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "50").
-						PodSet).
-					Workload,
-				utiltesting.MakeWorkload("c1", "eng-alpha").
+						Obj()).
+					Obj(),
+				*utiltesting.MakeWorkload("c1", "eng-alpha").
 					Queue("lq-c").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "75").
-						PodSet).
-					Workload,
+						Obj()).
+					Obj(),
 			},
 			wantAssignments: map[workload.Reference]kueue.Admission{
 				"eng-alpha/b0": *utiltesting.MakeAdmission("b", "one").Assignment(corev1.ResourceCPU, "on-demand", "10").Obj(),
@@ -1833,34 +1827,34 @@ func TestSchedule(t *testing.T) {
 		"fair sharing schedule singleton cqs and cq without cohort": {
 			enableFairSharing: true,
 			cohorts: []kueue.Cohort{
-				utiltesting.MakeCohort("A").
+				*utiltesting.MakeCohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "10").Obj(),
-					).Cohort,
-				utiltesting.MakeCohort("B").Cohort,
+					).Obj(),
+				*utiltesting.MakeCohort("B").Obj(),
 			},
 			additionalClusterQueues: []kueue.ClusterQueue{
-				utiltesting.MakeClusterQueue("a").
+				*utiltesting.MakeClusterQueue("a").
 					Cohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "0").Obj(),
 					).
-					ClusterQueue,
-				utiltesting.MakeClusterQueue("b").
+					Obj(),
+				*utiltesting.MakeClusterQueue("b").
 					Cohort("B").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "10").Obj(),
 					).
-					ClusterQueue,
-				utiltesting.MakeClusterQueue("c").
+					Obj(),
+				*utiltesting.MakeClusterQueue("c").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "10").Obj(),
 					).
-					ClusterQueue,
+					Obj(),
 			},
 			additionalLocalQueues: []kueue.LocalQueue{
 				*utiltesting.MakeLocalQueue("lq-a", "eng-alpha").ClusterQueue("a").Obj(),
@@ -1868,24 +1862,24 @@ func TestSchedule(t *testing.T) {
 				*utiltesting.MakeLocalQueue("lq-c", "eng-alpha").ClusterQueue("c").Obj(),
 			},
 			workloads: []kueue.Workload{
-				utiltesting.MakeWorkload("a1", "eng-alpha").
+				*utiltesting.MakeWorkload("a1", "eng-alpha").
 					Queue("lq-a").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "10").
-						PodSet).
-					Workload,
-				utiltesting.MakeWorkload("b1", "eng-alpha").
+						Obj()).
+					Obj(),
+				*utiltesting.MakeWorkload("b1", "eng-alpha").
 					Queue("lq-b").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "10").
-						PodSet).
-					Workload,
-				utiltesting.MakeWorkload("c1", "eng-alpha").
+						Obj()).
+					Obj(),
+				*utiltesting.MakeWorkload("c1", "eng-alpha").
 					Queue("lq-c").
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "10").
-						PodSet).
-					Workload,
+						Obj()).
+					Obj(),
 			},
 			wantAssignments: map[workload.Reference]kueue.Admission{
 				"eng-alpha/a1": *utiltesting.MakeAdmission("a", "one").Assignment(corev1.ResourceCPU, "on-demand", "10").Obj(),
@@ -1898,48 +1892,46 @@ func TestSchedule(t *testing.T) {
 		"fair sharing schedule highest priority first": {
 			enableFairSharing: true,
 			cohorts: []kueue.Cohort{
-				utiltesting.MakeCohort("A").
+				*utiltesting.MakeCohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "10").Obj(),
-					).Cohort,
-				utiltesting.MakeCohort("B").Cohort,
+					).Obj(),
+				*utiltesting.MakeCohort("B").Obj(),
 			},
 			additionalClusterQueues: []kueue.ClusterQueue{
-				utiltesting.MakeClusterQueue("b").
+				*utiltesting.MakeClusterQueue("b").
 					Cohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
-				utiltesting.MakeClusterQueue("c").
+					).Obj(),
+				*utiltesting.MakeClusterQueue("c").
 					Cohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
+					).Obj(),
 			},
 			additionalLocalQueues: []kueue.LocalQueue{
 				*utiltesting.MakeLocalQueue("lq-b", "eng-alpha").ClusterQueue("b").Obj(),
 				*utiltesting.MakeLocalQueue("lq-c", "eng-alpha").ClusterQueue("c").Obj(),
 			},
 			workloads: []kueue.Workload{
-				utiltesting.MakeWorkload("b1", "eng-alpha").
+				*utiltesting.MakeWorkload("b1", "eng-alpha").
 					Queue("lq-b").
 					Priority(99).
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "10").
-						PodSet).
-					Workload,
-				utiltesting.MakeWorkload("c1", "eng-alpha").
+						Obj()).
+					Obj(),
+				*utiltesting.MakeWorkload("c1", "eng-alpha").
 					Queue("lq-c").
 					Priority(101).
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "10").
-						PodSet).
-					Workload,
+						Obj()).
+					Obj(),
 			},
 			wantAssignments: map[workload.Reference]kueue.Admission{
 				"eng-alpha/c1": *utiltesting.MakeAdmission("c", "one").Assignment(corev1.ResourceCPU, "on-demand", "10").Obj(),
@@ -1952,50 +1944,48 @@ func TestSchedule(t *testing.T) {
 		"fair sharing schedule earliest timestamp first": {
 			enableFairSharing: true,
 			cohorts: []kueue.Cohort{
-				utiltesting.MakeCohort("A").
+				*utiltesting.MakeCohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "10").Obj(),
-					).Cohort,
-				utiltesting.MakeCohort("B").Cohort,
+					).Obj(),
+				*utiltesting.MakeCohort("B").Obj(),
 			},
 			additionalClusterQueues: []kueue.ClusterQueue{
-				utiltesting.MakeClusterQueue("b").
+				*utiltesting.MakeClusterQueue("b").
 					Cohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
-				utiltesting.MakeClusterQueue("c").
+					).Obj(),
+				*utiltesting.MakeClusterQueue("c").
 					Cohort("A").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("on-demand").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
+					).Obj(),
 			},
 			additionalLocalQueues: []kueue.LocalQueue{
 				*utiltesting.MakeLocalQueue("lq-b", "eng-alpha").ClusterQueue("b").Obj(),
 				*utiltesting.MakeLocalQueue("lq-c", "eng-alpha").ClusterQueue("c").Obj(),
 			},
 			workloads: []kueue.Workload{
-				utiltesting.MakeWorkload("b1", "eng-alpha").
+				*utiltesting.MakeWorkload("b1", "eng-alpha").
 					Creation(now.Add(time.Second)).
 					Queue("lq-b").
 					Priority(101).
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "10").
-						PodSet).
-					Workload,
-				utiltesting.MakeWorkload("c1", "eng-alpha").
+						Obj()).
+					Obj(),
+				*utiltesting.MakeWorkload("c1", "eng-alpha").
 					Creation(now).
 					Queue("lq-c").
 					Priority(101).
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "10").
-						PodSet).
-					Workload,
+						Obj()).
+					Obj(),
 			},
 			wantAssignments: map[workload.Reference]kueue.Admission{
 				"eng-alpha/c1": *utiltesting.MakeAdmission("c", "one").Assignment(corev1.ResourceCPU, "on-demand", "10").Obj(),
@@ -3251,48 +3241,46 @@ func TestSchedule(t *testing.T) {
 		//
 		"in a hierarchical cohort, workload borrowing less is scheduled first": {
 			cohorts: []kueue.Cohort{
-				utiltesting.MakeCohort("root").Cohort,
-				utiltesting.MakeCohort("guaranteed").
+				*utiltesting.MakeCohort("root").Obj(),
+				*utiltesting.MakeCohort("guaranteed").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("default").
 							Resource(corev1.ResourceCPU, "4").Obj(),
-					).Parent("root").Cohort,
+					).Parent("root").Obj(),
 			},
 			additionalClusterQueues: []kueue.ClusterQueue{
-				utiltesting.MakeClusterQueue("guaranteed").
+				*utiltesting.MakeClusterQueue("guaranteed").
 					Cohort("guaranteed").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("default").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
-				utiltesting.MakeClusterQueue("best-effort").
+					).Obj(),
+				*utiltesting.MakeClusterQueue("best-effort").
 					Cohort("root").
 					ResourceGroup(
 						*utiltesting.MakeFlavorQuotas("default").
 							Resource(corev1.ResourceCPU, "0").Obj(),
-					).
-					ClusterQueue,
+					).Obj(),
 			},
 			additionalLocalQueues: []kueue.LocalQueue{
 				*utiltesting.MakeLocalQueue("lq-guaranteed", "eng-alpha").ClusterQueue("guaranteed").Obj(),
 				*utiltesting.MakeLocalQueue("lq-best-effort", "eng-alpha").ClusterQueue("best-effort").Obj(),
 			},
 			workloads: []kueue.Workload{
-				utiltesting.MakeWorkload("guaranteed", "eng-alpha").
+				*utiltesting.MakeWorkload("guaranteed", "eng-alpha").
 					Queue("lq-guaranteed").
 					Priority(0).
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "4").
-						PodSet).
-					Workload,
-				utiltesting.MakeWorkload("best-effort", "eng-alpha").
+						Obj()).
+					Obj(),
+				*utiltesting.MakeWorkload("best-effort", "eng-alpha").
 					Queue("lq-best-effort").
 					Priority(3).
-					PodSets(utiltesting.MakePodSet("one", 1).
+					PodSets(*utiltesting.MakePodSet("one", 1).
 						Request(corev1.ResourceCPU, "4").
-						PodSet).
-					Workload,
+						Obj()).
+					Obj(),
 			},
 			wantAssignments: map[workload.Reference]kueue.Admission{
 				"eng-alpha/guaranteed": *utiltesting.MakeAdmission("guaranteed", "one").Assignment(corev1.ResourceCPU, "default", "4").Obj(),
@@ -3937,12 +3925,12 @@ func TestLastSchedulingContext(t *testing.T) {
 					).Obj(),
 			},
 			admittedWorkloads: []kueue.Workload{
-				utiltesting.MakeWorkload("low-1", "default").
+				*utiltesting.MakeWorkload("low-1", "default").
 					Queue("main").
 					Request(corev1.ResourceCPU, "50").
 					ReserveQuota(utiltesting.MakeAdmission("eng-alpha").Assignment(corev1.ResourceCPU, "on-demand", "50").Obj()).
 					Admitted(true).
-					Workload,
+					Obj(),
 			},
 			workloads: []kueue.Workload{
 				*utiltesting.MakeWorkload("preemptor", "default").
@@ -3951,12 +3939,12 @@ func TestLastSchedulingContext(t *testing.T) {
 					Obj(),
 			},
 			deleteWorkloads: []kueue.Workload{
-				utiltesting.MakeWorkload("low-1", "default").
+				*utiltesting.MakeWorkload("low-1", "default").
 					Queue("main").
 					Request(corev1.ResourceCPU, "50").
 					ReserveQuota(utiltesting.MakeAdmission("eng-alpha").Assignment(corev1.ResourceCPU, "on-demand", "50").Obj()).
 					Admitted(true).
-					Workload,
+					Obj(),
 			},
 			wantPreempted:                 sets.Set[workload.Reference]{},
 			wantAdmissionsOnFirstSchedule: map[workload.Reference]kueue.Admission{},
diff --git a/test/e2e/certmanager/suite_test.go b/test/e2e/certmanager/suite_test.go
index 0ec66cef3..7e6c0ca57 100644
--- a/test/e2e/certmanager/suite_test.go
+++ b/test/e2e/certmanager/suite_test.go
@@ -28,17 +28,15 @@ import (
 	"k8s.io/client-go/rest"
 	"sigs.k8s.io/controller-runtime/pkg/client"
 
-	"sigs.k8s.io/kueue/apis/config/v1beta1"
 	"sigs.k8s.io/kueue/test/util"
 )
 
 var (
-	k8sClient       client.WithWatch
-	ctx             context.Context
-	defaultKueueCfg *v1beta1.Configuration
-	cfg             *rest.Config
-	restClient      *rest.RESTClient
-	kueueNS         = util.GetKueueNamespace()
+	k8sClient  client.WithWatch
+	ctx        context.Context
+	cfg        *rest.Config
+	restClient *rest.RESTClient
+	kueueNS    = util.GetKueueNamespace()
 )
 
 func TestAPIs(t *testing.T) {
@@ -65,11 +63,4 @@ var _ = ginkgo.BeforeSuite(func() {
 		"Kueue and all required operators are available in the cluster",
 		"waitingTime", time.Since(waitForAvailableStart),
 	)
-	defaultKueueCfg = util.GetKueueConfiguration(ctx, k8sClient)
-})
-
-var _ = ginkgo.AfterSuite(func() {
-	util.ApplyKueueConfiguration(ctx, k8sClient, defaultKueueCfg)
-	util.RestartKueueController(ctx, k8sClient)
-	ginkgo.GinkgoLogr.Info("Default Kueue configuration restored")
 })
diff --git a/test/e2e/customconfigs/managejobswithoutqueuename_test.go b/test/e2e/customconfigs/managejobswithoutqueuename_test.go
index 9fd09c524..cfbaf458c 100644
--- a/test/e2e/customconfigs/managejobswithoutqueuename_test.go
+++ b/test/e2e/customconfigs/managejobswithoutqueuename_test.go
@@ -62,7 +62,7 @@ var _ = ginkgo.Describe("ManageJobsWithoutQueueName", ginkgo.Ordered, func() {
 	)
 
 	ginkgo.BeforeAll(func() {
-		updateKueueConfiguration(func(cfg *config.Configuration) {
+		util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *config.Configuration) {
 			cfg.ManageJobsWithoutQueueName = true
 		})
 	})
@@ -93,7 +93,7 @@ var _ = ginkgo.Describe("ManageJobsWithoutQueueName", ginkgo.Ordered, func() {
 			var jobLookupKey types.NamespacedName
 
 			ginkgo.By("setting local queue defulting as false", func() {
-				updateKueueConfiguration(func(cfg *config.Configuration) {
+				util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *config.Configuration) {
 					cfg.FeatureGates = map[string]bool{string(features.LocalQueueDefaulting): false}
 					cfg.ManageJobsWithoutQueueName = true
 				})
@@ -129,7 +129,7 @@ var _ = ginkgo.Describe("ManageJobsWithoutQueueName", ginkgo.Ordered, func() {
 				}, util.Timeout, util.Interval).Should(gomega.Succeed())
 			})
 			ginkgo.By("setting feature gates back to its original state", func() {
-				updateKueueConfiguration(func(cfg *config.Configuration) {
+				util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *config.Configuration) {
 					cfg.ManageJobsWithoutQueueName = true
 				})
 			})
@@ -915,7 +915,7 @@ var _ = ginkgo.Describe("ManageJobsWithoutQueueName without JobSet integration",
 	)
 
 	ginkgo.BeforeAll(func() {
-		updateKueueConfiguration(func(cfg *config.Configuration) {
+		util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *config.Configuration) {
 			cfg.ManageJobsWithoutQueueName = true
 			cfg.Integrations.Frameworks = slices.Filter(nil, cfg.Integrations.Frameworks, func(framework string) bool {
 				return framework != jobset.FrameworkName
diff --git a/test/e2e/customconfigs/objectretentionpolicies_test.go b/test/e2e/customconfigs/objectretentionpolicies_test.go
index 63035d540..fc76fc082 100644
--- a/test/e2e/customconfigs/objectretentionpolicies_test.go
+++ b/test/e2e/customconfigs/objectretentionpolicies_test.go
@@ -77,7 +77,7 @@ var _ = ginkgo.Describe("ObjectRetentionPolicies", ginkgo.Ordered, ginkgo.Contin
 			},
 		}
 
-		updateKueueConfiguration(func(cfg *configapi.Configuration) {
+		util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *configapi.Configuration) {
 			cfg.FeatureGates = nil
 			cfg.ObjectRetentionPolicies = nil
 			cfg.WaitForPodsReady = waitForPodsReady.DeepCopy()
@@ -105,7 +105,7 @@ var _ = ginkgo.Describe("ObjectRetentionPolicies", ginkgo.Ordered, ginkgo.Contin
 		})
 
 		ginkgo.By("Enable ObjectRetentionPolicies feature gate", func() {
-			updateKueueConfiguration(func(cfg *configapi.Configuration) {
+			util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *configapi.Configuration) {
 				cfg.FeatureGates = map[string]bool{string(features.ObjectRetentionPolicies): true}
 				cfg.ObjectRetentionPolicies = &configapi.ObjectRetentionPolicies{
 					Workloads: &configapi.WorkloadRetentionPolicy{
@@ -140,7 +140,7 @@ var _ = ginkgo.Describe("ObjectRetentionPolicies with TinyTimeout", ginkgo.Order
 	)
 
 	ginkgo.BeforeAll(func() {
-		updateKueueConfiguration(func(cfg *configapi.Configuration) {
+		util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *configapi.Configuration) {
 			cfg.FeatureGates = map[string]bool{string(features.ObjectRetentionPolicies): true}
 			cfg.ObjectRetentionPolicies = &configapi.ObjectRetentionPolicies{
 				Workloads: &configapi.WorkloadRetentionPolicy{
@@ -268,7 +268,7 @@ var _ = ginkgo.Describe("ObjectRetentionPolicies with TinyTimeout and RequeuingL
 	)
 
 	ginkgo.BeforeAll(func() {
-		updateKueueConfiguration(func(cfg *configapi.Configuration) {
+		util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *configapi.Configuration) {
 			cfg.FeatureGates = map[string]bool{string(features.ObjectRetentionPolicies): true}
 			cfg.ObjectRetentionPolicies = &configapi.ObjectRetentionPolicies{
 				Workloads: &configapi.WorkloadRetentionPolicy{
diff --git a/test/e2e/customconfigs/reconcile_test.go b/test/e2e/customconfigs/reconcile_test.go
index 588bd1325..a108b1e24 100644
--- a/test/e2e/customconfigs/reconcile_test.go
+++ b/test/e2e/customconfigs/reconcile_test.go
@@ -47,7 +47,7 @@ var _ = ginkgo.Describe("Job reconciliation with ManagedJobsNamespaceSelectorAlw
 	)
 
 	ginkgo.BeforeAll(func() {
-		updateKueueConfiguration(func(cfg *config.Configuration) {
+		util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *config.Configuration) {
 			cfg.FeatureGates = map[string]bool{string(features.ManagedJobsNamespaceSelectorAlwaysRespected): true}
 			cfg.ManagedJobsNamespaceSelector = &metav1.LabelSelector{
 				MatchExpressions: []metav1.LabelSelectorRequirement{
diff --git a/test/e2e/customconfigs/suite_test.go b/test/e2e/customconfigs/suite_test.go
index 29deb4aab..7bc7838a2 100644
--- a/test/e2e/customconfigs/suite_test.go
+++ b/test/e2e/customconfigs/suite_test.go
@@ -39,6 +39,7 @@ var (
 	ctx             context.Context
 	defaultKueueCfg *v1beta1.Configuration
 	kueueNS         = util.GetKueueNamespace()
+	kindClusterName = os.Getenv("KIND_CLUSTER_NAME")
 )
 
 func TestAPIs(t *testing.T) {
@@ -73,15 +74,6 @@ var _ = ginkgo.BeforeSuite(func() {
 
 var _ = ginkgo.AfterSuite(func() {
 	util.ApplyKueueConfiguration(ctx, k8sClient, defaultKueueCfg)
-	util.RestartKueueController(ctx, k8sClient)
+	util.RestartKueueController(ctx, k8sClient, kindClusterName)
 	ginkgo.GinkgoLogr.Info("Default Kueue configuration restored")
 })
-
-func updateKueueConfiguration(applyChanges func(cfg *v1beta1.Configuration)) {
-	configurationUpdate := time.Now()
-	config := defaultKueueCfg.DeepCopy()
-	applyChanges(config)
-	util.ApplyKueueConfiguration(ctx, k8sClient, config)
-	util.RestartKueueController(ctx, k8sClient)
-	ginkgo.GinkgoLogr.Info("Kueue configuration updated", "took", time.Since(configurationUpdate))
-}
diff --git a/test/e2e/customconfigs/waitforpodsready_test.go b/test/e2e/customconfigs/waitforpodsready_test.go
index f63fea4de..d55977d49 100644
--- a/test/e2e/customconfigs/waitforpodsready_test.go
+++ b/test/e2e/customconfigs/waitforpodsready_test.go
@@ -75,7 +75,7 @@ var _ = ginkgo.Describe("WaitForPodsReady with tiny Timeout and no RecoveryTimeo
 		}
 		util.MustCreate(ctx, k8sClient, metricsReaderClusterRoleBinding)
 
-		updateKueueConfiguration(func(cfg *configapi.Configuration) {
+		util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *configapi.Configuration) {
 			cfg.WaitForPodsReady = &configapi.WaitForPodsReady{
 				Enable:          true,
 				BlockAdmission:  ptr.To(true),
@@ -231,7 +231,7 @@ var _ = ginkgo.Describe("WaitForPodsReady with default Timeout and a tiny Recove
 		}
 		util.MustCreate(ctx, k8sClient, metricsReaderClusterRoleBinding)
 
-		updateKueueConfiguration(func(cfg *configapi.Configuration) {
+		util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *configapi.Configuration) {
 			cfg.WaitForPodsReady = &configapi.WaitForPodsReady{
 				Enable:          true,
 				BlockAdmission:  ptr.To(true),
@@ -376,7 +376,7 @@ var _ = ginkgo.Describe("WaitForPodsReady with default Timeout and a long Recove
 		}
 		util.MustCreate(ctx, k8sClient, metricsReaderClusterRoleBinding)
 
-		updateKueueConfiguration(func(cfg *configapi.Configuration) {
+		util.UpdateKueueConfiguration(ctx, k8sClient, defaultKueueCfg, kindClusterName, func(cfg *configapi.Configuration) {
 			cfg.WaitForPodsReady = &configapi.WaitForPodsReady{
 				Enable:          true,
 				BlockAdmission:  ptr.To(true),
diff --git a/test/e2e/kueueviz/package-lock.json b/test/e2e/kueueviz/package-lock.json
index 985e81d93..d9ac00460 100644
--- a/test/e2e/kueueviz/package-lock.json
+++ b/test/e2e/kueueviz/package-lock.json
@@ -1535,15 +1535,16 @@
       }
     },
     "node_modules/form-data": {
-      "version": "4.0.2",
-      "resolved": "https://registry.npmjs.org/form-data/-/form-data-4.0.2.tgz",
-      "integrity": "sha512-hGfm/slu0ZabnNt4oaRZ6uREyfCj6P4fT/n6A1rGV+Z0VdGXjfOhVUpkn6qVQONHGIFwmveGXyDs75+nr6FM8w==",
+      "version": "4.0.4",
+      "resolved": "https://registry.npmjs.org/form-data/-/form-data-4.0.4.tgz",
+      "integrity": "sha512-KrGhL9Q4zjj0kiUt5OO4Mr/A/jlI2jDYs5eHBpYHPcBEVSiipAvn2Ko2HnPe20rmcuuvMHNdZFp+4IlGTMF0Ow==",
       "dev": true,
       "license": "MIT",
       "dependencies": {
         "asynckit": "^0.4.0",
         "combined-stream": "^1.0.8",
         "es-set-tostringtag": "^2.1.0",
+        "hasown": "^2.0.2",
         "mime-types": "^2.1.12"
       },
       "engines": {
diff --git a/test/util/e2e.go b/test/util/e2e.go
index bd55e3467..bbef8c416 100644
--- a/test/util/e2e.go
+++ b/test/util/e2e.go
@@ -205,9 +205,9 @@ func CreateVisibilityClient(user string) visibilityv1beta1.VisibilityV1beta1Inte
 	return visibilityClient
 }
 
-func rolloutOperatorDeployment(ctx context.Context, k8sClient client.Client, key types.NamespacedName) {
+func rolloutOperatorDeployment(ctx context.Context, k8sClient client.Client, key types.NamespacedName, kindClusterName string) {
 	// Export logs before the rollout to preserve logs from the previous version.
-	exportKindLogs(ctx)
+	exportKindLogs(ctx, kindClusterName)
 
 	deployment := &appsv1.Deployment{}
 	var deploymentCondition *appsv1.DeploymentCondition
@@ -238,14 +238,14 @@ func rolloutOperatorDeployment(ctx context.Context, k8sClient client.Client, key
 	}, StartUpTimeout, Interval).Should(gomega.Succeed())
 }
 
-func exportKindLogs(ctx context.Context) {
+func exportKindLogs(ctx context.Context, kindClusterName string) {
 	// Path to the kind binary
 	kind := os.Getenv("KIND")
 	// Path to the artifacts
 	artifacts := os.Getenv("ARTIFACTS")
 
 	if kind != "" && artifacts != "" {
-		cmd := exec.CommandContext(ctx, kind, "export", "logs", artifacts)
+		cmd := exec.CommandContext(ctx, kind, "export", "logs", "-n", kindClusterName, artifacts)
 		cmd.Stdout = ginkgo.GinkgoWriter
 		cmd.Stderr = ginkgo.GinkgoWriter
 		gomega.Expect(cmd.Run()).To(gomega.Succeed())
@@ -344,10 +344,10 @@ func ApplyKueueConfiguration(ctx context.Context, k8sClient client.Client, kueue
 	}, Timeout, Interval).Should(gomega.Succeed())
 }
 
-func RestartKueueController(ctx context.Context, k8sClient client.Client) {
+func RestartKueueController(ctx context.Context, k8sClient client.Client, kindClusterName string) {
 	kueueNS := GetKueueNamespace()
 	kcmKey := types.NamespacedName{Namespace: kueueNS, Name: "kueue-controller-manager"}
-	rolloutOperatorDeployment(ctx, k8sClient, kcmKey)
+	rolloutOperatorDeployment(ctx, k8sClient, kcmKey, kindClusterName)
 }
 
 func WaitForActivePodsAndTerminate(ctx context.Context, k8sClient client.Client, restClient *rest.RESTClient, cfg *rest.Config, namespace string, activePodsCount, exitCode int, opts ...client.ListOption) {
@@ -445,3 +445,12 @@ func WaitForPodRunning(ctx context.Context, k8sClient client.Client, pod *corev1
 		g.Expect(createdPod.Status.Phase).To(gomega.Equal(corev1.PodRunning))
 	}, LongTimeout, Interval).Should(gomega.Succeed())
 }
+
+func UpdateKueueConfiguration(ctx context.Context, k8sClient client.Client, config *configapi.Configuration, kindClusterName string, applyChanges func(cfg *configapi.Configuration)) {
+	configurationUpdate := time.Now()
+	config = config.DeepCopy()
+	applyChanges(config)
+	ApplyKueueConfiguration(ctx, k8sClient, config)
+	RestartKueueController(ctx, k8sClient, kindClusterName)
+	ginkgo.GinkgoLogr.Info("Kueue configuration updated", "took", time.Since(configurationUpdate))
+}