Add slack channel for workload-aware-scheduling by helayoty · Pull Request #8851 · kubernetes/community

helayoty · 2026-02-13T19:46:21Z

Following up the conversation with SIG-Scheduling, SIG-apps, and WG-device-management. The decision is to create a dedicated slack channel for WAS (Workload-aware-scheduling) and TAS (Topology-aware-scheduling) workstream.

cc @mm4tt @johnbelamaric @dom4ha @wojtek-t @kannon92 @andreyvelich

Which issue(s) this PR fixes:
Fixes #8849

Signed-off-by: Heba Elayoty <heelayot@microsoft.com>

k8s-ci-robot · 2026-02-13T19:46:32Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: helayoty
Once this PR has been reviewed and has the lgtm label, please assign dylangraham for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

communication/slack-config/OWNERS

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

k8s-ci-robot · 2026-02-13T19:46:39Z

The OWNERS file contains untrusted users, which makes it INVALID. The following users are mentioned in OWNERS file(s) but are untrusted for the following reasons. One way to make the user trusted is to add them as members of the kubernetes org. You can then trigger verification by writing /verify-owners in a comment.

sig-scheduling-approvers
- User is not a member of the org. Satisfy at least one of these conditions to make the user trusted.

jberkus · 2026-02-13T23:23:03Z

communication/slack-config/sig-scheduling/config.yaml

+  - name: topology-aware-scheduling
+  - name: workload-aware-scheduling


Wait, are you adding topology-aware-scheduling as well?

It's definitely debatable. I'd definitely leave the scheduling aspects (including topology scheduling) to sig-scheduling core.

The reasonable border between such channel (or WG) should be API and how scheduler interacts with the rest of the ecosystem including controllers, autoscalers, kubelet etc. The scheduling topics should be discussed on the sig-scheduling channel.

Wait, are you adding topology-aware-scheduling as well?

I discovered that there is a channel with this name already! So just included it under scheduling.

Ah, makes sense

This is a slack channel that predates what we call Topology aware scheduling. I think its was more about topology aware within the node (https://github.com/k8stopologyawareschedwg).

This was probably more aligned with kubelet but I'm actually not sure if this channel is still used.
cc @ffromani @swatisehgal

Let's not adopt it to sig-scheduling if we aren't completely sure its history.

dom4ha

WDYT? @macsko @sanposhiho @wojtek-t @mm4tt

dom4ha · 2026-02-13T23:30:24Z

communication/slack-config/channels.yaml

    archived: true
  - name: windows-containerd
  - name: workshop-chat
+  - name: workload-aware-scheduling


As commented in #8849 (comment), we could alternatively use wg-workload-awareness or simply workload-awareness.

[..] wg-workload-awareness [..]

jfyi, this would be misleading since it's not an actual WG

skipping the wg prefix, we'd have workload-awarness then

Giving it a second thought, having a name that clearly indicate the WAS effort "workload-aware-scheduling" will increase discoverability of the channel, so I'm fine with the full name as well.

dom4ha · 2026-02-13T23:35:56Z

communication/slack-config/sig-scheduling/config.yaml

+  - name: topology-aware-scheduling
+  - name: workload-aware-scheduling


It's definitely debatable. I'd definitely leave the scheduling aspects (including topology scheduling) to sig-scheduling core.

The reasonable border between such channel (or WG) should be API and how scheduler interacts with the rest of the ecosystem including controllers, autoscalers, kubelet etc. The scheduling topics should be discussed on the sig-scheduling channel.

jberkus · 2026-02-13T23:40:40Z

/hold

In addition to the test fail (and possible channel duplication), discussion about what to name the new channel is ongoing

sanposhiho · 2026-02-14T09:57:12Z

Why not discuss all the things in sig-scheduling slack channel? There's a few messages even today, and I don't think the channel is overwhelmed / mixed with various different topics.

From the past experience, i feel like we generally kinda hesitate to create various channels unnecessarily. I don't see a strong motivation here.

sanposhiho · 2026-02-14T18:36:33Z

@kannon92 I suppose you meant to leave this comment here
kubernetes/kubernetes#132192 (comment)

For example, if I have questions about Job or JobSet workload aware scheduling is sig-scheduling the best place for that?

Yes. I can imagine some questions might then be asked to move to sig-app channel though, if that's too sig-app perspective questions.

We are not WG right now - how do all people notice there is a dedicated channel for WAS and the integration? My concern is that

some people start using new channel, while others use the existing sig-scheduling channel for WAS discussion. Resulting in discussions to spread on multiple channels.
some people wanted to follow the WAS discussion happening on slack, but miss them because they don't notice the channel. Resulting in discussions/announcements to be hidden from many people who actually are interested in.

sanposhiho · 2026-02-14T18:44:49Z

...or, in other words, if many maintainers argue it is necessary/convenient to create such a dedicated place for the WAS discussions related to various SIGs/WGs, that might be a signal that we are needing WG.

kannon92 · 2026-02-14T19:10:54Z

Doh! Yes I meant to post the respond on slack here. 🙈

helayoty · 2026-02-15T00:54:45Z

Why not discuss all the things in sig-scheduling slack channel? There's a few messages even today, and I don't think the channel is overwhelmed / mixed with various different topics.

From the past experience, i feel like we generally kinda hesitate to create various channels unnecessarily. I don't see a strong motivation here.

We have discussed this topic in the last Workload API sync meeting. The conclusion is that while we still don't want to go furture and create WG until we see a real neccessary need, the Workload-aware integration will expand beyond scheduling only (sig-apps, sig-autoschaling, LWS, JobSet, etc... ).
Therefore, we decided to move forward and create a dedicated label and channel so community can track this work.

helayoty · 2026-02-15T00:56:41Z

some people start using new channel, while others use the existing sig-scheduling channel for WAS discussion. Resulting in discussions to spread on multiple channels.
some people wanted to follow the WAS discussion happening on slack, but miss them because they don't notice the channel. Resulting in discussions/announcements to be hidden from many people who actually are interested in.

This will be our responsibility to make it visible and noticable.

helayoty · 2026-02-15T00:58:11Z

In addition to the test fail (and possible channel duplication), discussion about what to name the new channel is ongoing

@jberkus this is not a duplicated channel, this channel has been there already and no one know anything about it. Therefore, sig-scheduling needs to start mention it for topology-aware discussion and link it to both sig-scheduling and workload-aware when neccessary.

dom4ha · 2026-02-17T12:28:48Z

LGTM for "workload-aware-scheduling" channel name to increase discoverability of the WAS effort.

The only question is who the chanel name would evolve in case we formed a WG? Can it remain the same?

Create WAS slack channel

dff4000

Signed-off-by: Heba Elayoty <heelayot@microsoft.com>

k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. area/community-management area/slack-management Issues or PRs related to the Slack Management subproject labels Feb 13, 2026

k8s-ci-robot requested a review from jeefy February 13, 2026 19:46

k8s-ci-robot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Feb 13, 2026

k8s-ci-robot requested a review from mrbobbytables February 13, 2026 19:46

k8s-ci-robot added the sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. label Feb 13, 2026

k8s-ci-robot added the do-not-merge/invalid-owners-file Indicates that a PR should not merge because it has an invalid OWNERS file in it. label Feb 13, 2026

helayoty mentioned this pull request Feb 13, 2026

REQUEST: New Slack channel workload-aware-scheduling #8849

Open

jberkus reviewed Feb 13, 2026

View reviewed changes

dom4ha reviewed Feb 13, 2026

View reviewed changes

k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 13, 2026

helayoty requested a review from jberkus February 15, 2026 01:01

		- name: topology-aware-scheduling
		- name: workload-aware-scheduling

Conversation

helayoty commented Feb 13, 2026

Uh oh!

k8s-ci-robot commented Feb 13, 2026

Uh oh!

k8s-ci-robot commented Feb 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dom4ha left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jberkus commented Feb 13, 2026

Uh oh!

sanposhiho commented Feb 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sanposhiho commented Feb 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sanposhiho commented Feb 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kannon92 commented Feb 14, 2026

Uh oh!

helayoty commented Feb 15, 2026

Uh oh!

helayoty commented Feb 15, 2026

Uh oh!

helayoty commented Feb 15, 2026

Uh oh!

dom4ha commented Feb 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

sanposhiho commented Feb 14, 2026 •

edited

Loading

sanposhiho commented Feb 14, 2026 •

edited

Loading

sanposhiho commented Feb 14, 2026 •

edited

Loading