Skip to content

Fix typo in KEP 4671 #5664

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 23, 2025
+6 −6
Merged

Fix typo in KEP 4671 #5664

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions keps/sig-scheduling/4671-gang-scheduling/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -281,8 +281,8 @@ spec:
```yaml
apiVersion: v1
kind: Pod
name:
jobset-job-1-abc123
metadata:
name: jobset-job-1-abc123
spec:
...
workload:
Expand All @@ -293,15 +293,15 @@ spec:

```

We decided for this option because it is more succint and makes the role of a pod clear just
We decided for this option because it is more succinct and makes the role of a pod clear just
from inspecting the pod (and simple/efficient to group).
We acknowledge the fact that this option may require additional minor changes in the controllers
to adopt this pattern (e.g. for LeaderWorkerSet we will need to populate the pod template
similarly that we currently populate the labels).

The primary alternative we consider was to introduce the the `PodGroupSelector` on each `PodGroup`
The primary alternative we consider was to introduce the `PodGroupSelector` on each `PodGroup`
to identify pods belonging to it. However, with this pattern:
- there are additional corner cases (e.g. a pod links to a workload but none of its PodGroups matching
- there are additional corner cases (e.g. a pod links to a workload but none of its PodGroups match
that pod)
- for replicated gang, we can't use the full label selector, but rather support specifying only the
label key, similar to `MatchLabelKeys` in pod affinity
Expand Down Expand Up @@ -438,7 +438,7 @@ For `Beta`, we want to also touch requirements (2) and (3) by extending the sche
a new dedicated phase (tentatively called Workload). In that phase,
kube-scheduler will be looking at all pods from a gang (part of `Workload`) and compute the placement
for all of these pods in a single scheduling cycle. Those placements will be stored only in-memory and
block the required resources from scheduling. Tentively we plan to use `NominatedNodeName` field for it.
block the required resources from scheduling. Tentatively we plan to use `NominatedNodeName` field for it.
After that, pods will go through regular pod-by-pod scheduling phases (including Filter and Score)
with a nomination as a form of validation the proposed placement and execution of this placement decision.
Therefore we expect the order of processing pods won't ever be important, but all-or-nothing nature of
Expand Down