PR for above enhancement: #3334

/milestone v1.25

Hello @klueska, @arpitsardhana 👋, 1.25 Enhancements team here.

Just checking in as we approach enhancements freeze on 18:00 PST on Thursday June 16, 2022.

For note, This enhancement is targeting for stage alpha for 1.25 (correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP file using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable
• KEP has a updated detailed test plan section filled out
• KEP has up to date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements.

Looks like for this one, we would need to update the open KEP PR #3334 for following & get it merged by Enhancements Freeze:

• update the KEP README.md to add more details in the Test Plan section, in furtherance of the goal of increasing reliability across the project.

For note, the status of this enhancement is marked as at risk. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

Thanks @Priyankasaggu11929 for heads up!
I will update PR with test plan accordingly

@Priyankasaggu11929 Updated the KEP PR #3334 with test plan section and adhered to format
Let me know if you see any further concerns

Hello @arpitsardhana, thanks for the heads up & quick update 🙂

Now we require to just get the open KEP PR merged before the updated enhancements freeze on Thursday, June 23, 2022 at 18:00 PM PT. Thank you!

Just one nit, we need marking this checkbox, in the Test Plan section:

[ ] I/we understand the owners of the involved components may require updates to
existing tests to make this code solid enough prior to committing the changes necessary
to implement this enhancement.

Updated the PR with above nit! Thanks

With KEP PR #3334 merged, the PR is ready for the 1.25 Enhancements Freeze.

For note, the status is now marked as Tracked. Thank you so much! 🙂

Hi @klueska, Enhancements team here again 👋

Checking in as we approach Code Freeze at 01:00 UTC on Wednesday, 3rd August 2022.

Please ensure that the following items are completed before the code-freeze:

• All PRs to the Kubernetes repo that are related to your enhancement are linked in the above issue description (for tracking purposes).
• All PRs are fully merged by the code freeze deadline.
  KEP-3327: Add CPUManager policy option to align CPUs by Socket instead of by NUMA node kubernetes#111278
  Let me know if there are any additional k/k PRs besides the one listed above

Currently, the status of the enhancement is marked as at-risk

Thanks :)

Pull Request for feature: kubernetes/kubernetes#111278

Hey @arpitsardhana, reaching out again as we approach Code Freeze at 01:00 UTC on this Wednesday i.e 3rd August 2022.
Try to get this PR kubernetes/kubernetes#111278 merged before the code-freeze :)
The status of the enhancement is still marked as at-risk

Issues to track for beta:

1. Evaluate if AlignBySocket should be part of TopologyManager
2. Correct place for ValidateStaticPolicyOptions()
3. Unified container manager test cases covering multiple hint provider (under "pkg/kubelet/cm")
4. Improve FakeManager implementation to be more generic

Noted all issues to be tracked for Beta @klueska @fromanirh @swatisehgal

With k/k code PR kubernetes/kubernetes#111278 merged now, this enhancement is marked as tracked for 1.25 code freeze. Thank you so much @arpitsardhana.

Just out of curiosity, why was this moved to "tracked/no"? The code for this merged as an alpha release in 1.25 and we plan to transition it to beta in 1.26. Shouldn't it be stage/alpha instead?

Hey @klueska 👋
As per the new release opt-in process SIG Leads are supposed to apply lead-opted-in label to the KEP issue to opt it in for the release cycle.

Please refer:
https://groups.google.com/a/kubernetes.io/g/dev/c/R1afPL7zpT4/m/lKv7eg3jBwAJ
https://www.kubernetes.dev/blog/2022/09/09/enhancements-opt-in/
Example KEP issue: #3325 (comment)

cc: @rhockenbury

Even though the code to bring this enhancement to alpha has already merged? I would expect a stage/alpha label in this case.

Hi @klueska

Yes, enhancements need to opt into the current release cycle for when they are planned to graduate. We'll get this opted into v1.26 for beta, but for graduation to stable later on, you'll need to opt in again. The opt in process just involves applying the lead-opted-in label. This is targeting beta for 1.26 so the stage label should reflect that target stage. Let me know if you have any more questions.

/label lead-opted-in
/milestone v1.26
/label tracked/yes
/remove-label tracked/no
/stage beta

@Atharva-Shinde Thanks for reminder. As of now we plan to keep feature in alpha. Since there is additional work we want to do
I will update kep.yaml shortly to reflect that

Hey @arpitsardhana, thanks for the update. I've updated the issue labels and have edited my comment with alpha stage. For further communications I've now tagged you in the comment too :)

Hello @klueska @arpitsardhana 👋, just a quick check-in again, as we approach the 1.26 Enhancements freeze.

Please plan to get the action items mentioned in my comment above done before Enhancements freeze on 18:00 PDT on Thursday 6th October 2022 i.e tomorrow

For note, the current status of the enhancement is marked at-risk :)

@Atharva-Shinde I have updated beta & stable target for KEP-3327.
I did see need to update prod-readiness.

MR: #3590
Let’s me know if any additional work i required.

Hello 👋, 1.26 Enhancements Lead here.

Unfortunately, this enhancement did not meet requirements for enhancements freeze.

If you still wish to progress this enhancement in v1.26, please file an exception request. Thanks!

/milestone clear
/label tracked/no
/remove-label tracked/yes
/remove-label lead-opted-in

@rhockenbury @Atharva-Shinde I am not sure if i understand the action.
I have raised MR to set the beta target to 1.27.
The feature is alpha in 1.26 and we want to keep the status quo such as keep it alpha in 1.27

I have raised MR to update the beta target in KEP. My question is, do we need anything additional? I dont intend to commit any extra code with regards to align-by-socket, does that mean it wont be available in 1.26 even as alpha?

No, we are set here and nothing additional is needed. This will remain in alpha for 1.26, and you'll need to opt in again when the 1.27 cycle starts to graduate the enhancements to beta.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

/remove-lifecycle rotten

is this KEP will be worked on in 1.28?

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale