/milestone v1.12
/sig scheduling
/stage alpha

/kind feature

/cc @MistyHacks , @justaugustus :)

@zparnold for 1.12 🙌

@k82cn --

It looks like this feature is currently in the Kubernetes 1.12 Milestone.

If that is still accurate, please ensure that this issue is up-to-date with ALL of the following information:

• One-line feature description (can be used as a release note):
• Primary contact (assignee):
• Responsible SIGs:
• Design proposal link (community repo):
• Link to e2e and/or unit tests:
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
• Approver (likely from SIG/area to which feature belongs):
• Feature target (which target equals to which milestone):
  • Alpha release target (x.y)
  • Beta release target (x.y)
  • Stable release target (x.y)

Set the following:

• Description
• Assignee(s)
• Labels:
  • stage/{alpha,beta,stable}
  • sig/*
  • kind/feature

Please note that the Features Freeze is July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.

In addition, please be aware of the following relevant deadlines:

• Docs deadline (open placeholder PRs): 8/21
• Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.

Happy shipping!

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

Done, in issue description :)

Thanks @k82cn!

@k82cn -- would you mind updating this issue to include a one-line description of what exactly "gang scheduling" is? Detail is included in the KEP, but this is not easy to glean from the perspective of a casual passerby.

Hey there! @k82cn I'm the wrangler for the Docs this release. Is there any chance I could have you open up a docs PR against the release-1.12 branch as a placeholder? That gives us more confidence in the feature shipping in this release and gives me something to work with when we start doing reviews/edits. Thanks! If this feature does not require docs, could you please update the features tracking spreadsheet to reflect it?

Given that this feature is planned on being implemented out of tree - as part of kube-arbitrator repo, should this be tracked as part of a k8s release?

The design for this is wanting to add a field to pod spec (though that has definitely not reached agreement). Anything wanting integration like that needs to be represented in the release planning.

@k82cn / @vishh --
Would you mind updating the one-line description for the feature, per my earlier comment (#583 (comment)):

@k82cn -- would you mind updating this issue to include a one-line description of what exactly "gang scheduling" is? Detail is included in the KEP, but this is not easy to glean from the perspective of a casual passerby.

@justaugustus , @zparnold , sure, I'll update it today :)

Updated description for gang-scheduling; and here's the placeholder of doc kubernetes/website#9981 :)

Thanks @k82cn! :)

Folks, I'm here from the docs queue. Hoping it's not too late: we should seriously consider a better name for this feature, at least as we expose it to users. "Gang scheduling" is unfortunate for many reasons which I'm happy to elaborate if need be, but hope y'all can figure it out for yourselves.

@k82cn -- I'm inclined to agree with Jennifer's sentiment:

Folks, I'm here from the docs queue. Hoping it's not too late: we should seriously consider a better name for this feature, at least as we expose it to users. "Gang scheduling" is unfortunate for many reasons which I'm happy to elaborate if need be, but hope y'all can figure it out for yourselves.

Any chance we can adjust the name, before this is officially out in the wild?

Potential suggestions:

• Bulk scheduling
• Group scheduling
• Batch scheduling
• Pool scheduling

@Bradamant3 , @justaugustus , thanks for your reminders; I think "Group scheduling" will be better, which maps to our new API PodGroup.

/cc @vishh @bsalamat to see if any more comments about the name.

+1 on avoiding colloquial terms in feature / concept names. This kind of naming can be especially confusing to people whose first language is not English. In addition, knowing the name of a feature / concept should give you some idea of what it does, and "gang" doesn't really meet this test.

"group scheduling" seemed to me on first acquaintance to map well to what the feature actually does, particularly from a new user perspective

Unfortunately, the term "gang scheduling" IS the established technical term for this feature and has been widely used for decades:
https://en.wikipedia.org/wiki/Gang_scheduling

So even if we don't name the feature "gang scheduling", we'll need to refer to it in our documentation so that users can relate it to what they know and search for related technical information.

"Batch scheduling" has a different meaning, and a pre-existing meaning within Kubernetes, so we can't use that.

"Pool" has a different meaning, as well.

"Group scheduling" is ok, though "group" is a pretty generic term, and there are zero relevant search results currently, so it is likely to require more explanation.

"Collective" or "collection" scheduling would be another possibility, but have even worse search characteristics than "group scheduling". "Set scheduling" and "bulk scheduling" aren't better.

Using "placement" doesn't work better than "scheduling", particularly since gang scheduling generally does involve time-deferred scheduling in addition to placement.

So, from a technical documentation point of view, "gang scheduling" is the most understandable term, and "group scheduling" seems like the least-bad alternative, unless we just invent a new, distinctive, unambiguous term.

I guess a general issue is how much of all of Computer Science and Software Engineering are we going to try to fix.

How about coscheduling?

https://en.wikipedia.org/wiki/Coscheduling

Since we use pods for co-placement, I don't think it would be ambiguous.

Considering the progress of design doc review, prefer to move this to 1.13 .

/cc @vishh , @bsalamat

Thanks for the update, @k82cn!
/milestone v1.13

@k82cn This release is targeted to be more ‘stable’ and will have an aggressive timeline. Do you have a high level of confidence it will meet the following deadlines? If yes, we will keep it in 1.13 tracking. Thanks!
Docs (open placeholder PRs): 11/8
Code Slush: 11/9
Code Freeze Begins: 11/15
Docs Complete and Reviewed: 11/27

This feature will be built in an incubator project, outside of the core. So, stability is not an issue. We just want to ensure that our design is finalized in 1.13.

What parts of this design (if any) are expected to land in k/k as part of the 1.13 release cycle?

Is kubernetes/kubernetes#61012 redundant as a tracking issue for Coscheduling?

What parts of this design (if any) are expected to land in k/k as part of the 1.13 release cycle?

@spiffxp , we will not land any changes to k/k; we'll implement this feature in https://github.com/kubernetes-sigs/kube-batch/ for now. We only commit design doc here (1.13), as we'll migrate it into k/k when it's ready :)

@k82cn considering the commitment for 1.13 is a design doc and not code in k/k, I suggest we stop tracking it for this release. this means we will drop /milestone v1.13 and flip /tracked to no. Let me know if you have any objection/concern regarding this.

@kacole2

/milestone clear

@AishSundar , @kacole2 , that's ok to me , thanks :)

@k82cn Hello - I’m the enhancement’s lead for 1.14 and I’m checking in on this issue to see what work (if any) is being planned for the 1.14 release. Enhancements freeze is Jan 29th and I want to remind that all enhancements must have a KEP

Thanks very much for your reminder ! We do not have work in 1.14 for this feature :)

I'm the Enhancement Lead for 1.15. Is this feature going to be graduating alpha/beta/stable stages in 1.15? Please let me know so it can be tracked properly and added to the spreadsheet.

Once coding begins, please list all relevant k/k PRs in this issue so they can be tracked properly.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Hi @k82cn , I'm the 1.16 Enhancement Shadow. Is this feature going to be graduating alpha/beta/stable stages in 1.16? Please let me know so it can be added to the 1.16 Tracking Spreadsheet. If it's not's graduating, I will remove it from the milestone and change the tracked label.

Once coding begins or if it already has, please list all relevant k/k PRs in this issue so they can be tracked properly.

Milestone dates are Enhancement Freeze 7/30 and Code Freeze 8/29.
Thank you.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

@fejta-bot: Closing this issue.