/sig node

Hi @ddebroy! 1.24 Enhancements team here. Just checking in as we approach enhancements freeze at 18:00pm PT on Thursday Feb 3rd. This enhancement is targeting alpha for 1.24.

Here’s where this enhancement currently stands:

• Updated KEP file using the latest template has been merged into the k/enhancements repo. - INCLUDED IN PR KEP-3085: Add KEP for Pod network ready condition #3087
• KEP status is marked as implementable for latest-milestone: 1.24 - INCLUDED IN PR KEP-3085: Add KEP for Pod network ready condition #3087
• KEP has a test plan section filled out. - INCLUDED IN PR KEP-3085: Add KEP for Pod network ready condition #3087
• KEP has up to date graduation criteria. - INCLUDED IN PR KEP-3085: Add KEP for Pod network ready condition #3087
• KEP has a production readiness review that has been completed and merged into k/enhancements. - INCLUDED IN PR KEP-3085: Add KEP for Pod network ready condition #3087

Please plan to merge #3087 by enhancements freeze to complete the above items. The status of this enhancement is at risk. Thanks!

PRR for the KEP is complete for 1.24. Waiting on final reviews from sig-node.

The Enhancements Freeze is now in effect and this enhancement is removed from the release.
Please feel free to file an exception.

/milestone clear

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

/remove-lifecycle stale

/milestone v1.25

Hello @ddebroy 👋, 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 #3087 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!

I have updated the Test Plan section as recommended based on the latest template pointed out above.

Thanks for the quick update, @ddebroy 🙂

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

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

Hello @ddebroy 👋, 1.25 Release Docs Shadow here.

This enhancement is marked as ‘Needs Docs’ for the 1.25 release. Please follow the steps detailed in the documentation to open a PR against the dev-1.25 branch in the k/website repo. This PR can be just a placeholder at this time and must be created by August 4.


Also, take a look at Documenting for a release to familiarize yourself with the docs requirement for the release. Thank you!

Hi @ddebroy 👋

Checking in once more as we approach 1.25 code freeze at 01:00 UTC on Wednesday, 3rd August 2022.

Please ensure the following items are completed:

• 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.
  • Introduce PodHasNetwork condition for pods kubernetes#111358

Please verify, if there are any additional k/k PRs besides the ones listed above.

Please plan to get the open k/k merged by the code freeze deadline. The status of the enhancement is currently marked as at-risk.

Please also update the issue description with the relevant links for tracking purpose. Thank you so much!

Hey @ddebroy, I want to update the description to remove the beta field and add some PRs that I have waiting for this. I am unable to edit it as it was created by you.

Can you add this under alpha (KEP (k/enhancements) update PR(s): #3778)

And can you add kubernetes/website#40945 to the website section so we track some of the PRs in the issue.

Hello @ddebroy! 1.28 Docs Shadow here.

Does this enhancement work planned for 1.28 require any new docs or modification to existing docs?

If so, please follows the steps here to open a PR against dev-1.28 branch in the k/website repo. This PR can be just a placeholder at this time and must be created before Thursday 20th July 2023.

Also, take a look at Documenting for a release to get yourself familiarize with the docs requirement for the release.

Thank you!

Hey @ddebroy , could you please create a docs PR even if it is a draft PR with no content yet against dev-1.28 branch in the k/website repo. The deadline to create this draft PR is Thursday 20th July 2023.

I believe this kubernetes/website#40945 should suffice.

I have one where I need to update the blog post from last year to say that it has been renamed.

Hey again @ddebroy 👋

Just checking in as we approach Code freeze at 01:00 UTC Friday, 19th July 2023.

Here’s the enhancement’s state for the upcoming code freeze:

• All the PRs that are related to your enhancement are linked in the above issue description (for tracking purposes). This includes code, tests, and documentation-related PR/s.
• All code-related PR/s are merged or are in a merge-ready state (i.e. they have approved and lgtm labels applied) by the code freeze deadline. This includes any tests related to PR/s too.

This is the code related PR/s that I found on this KEP issue:

• Introduce PodHasNetwork condition for pods kubernetes#111358
• feat: rename PodHasNetwork to PodReadyToStartContainers kubernetes#117702

Please keep the issue description up-to-date with all the PR/s that are associated with this KEP and let me know if there are other PR/s in k/k we should be tracking for this KEP.

As always, we are here to help if any questions come up. Thanks!

Thank you! I'm going to see if I can get some edit access to this issue so I can update the issue.

Hey @kannon92 👋 Enhancements Lead here,
With kubernetes/kubernetes#111358 and kubernetes/kubernetes#117702 merged, this enhancement is now tracked for v1.28 Code Freeze. Thanks!

Thank you @Atharva-Shinde! I'm planning on copying this and creating a new issue so I can keep this up-to-date.

For next release, I'd like to target this for beta. One item I think may need to be addressed (kubernetes/kubernetes#117702 (comment)).

At Beta stage, I believe the recommendation is to have the Condition name going through an official API review and shifted out of the temporary pkg/kubelet/types/constants.go below?

@liggitt is this a common way to add new conditions to pods? I guess in beta we would want to move the condition name to be here (https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/api/core/v1/types.go#L2834?)

once we commit to publishing named conditions, we have to assume that external integrators will start to trigger off of those, so we treat it like an API surface. Yes, moving the constant to the api types package would be a good place to put it, and would pull in API review as a side-effect

once we commit to publishing named conditions, we have to assume that external integrators will start to trigger off of those, so we treat it like an API surface. Yes, moving the constant to the api types package would be a good place to put it, and would pull in API review as a side-effect

That makes sense. I think that can be a good call for Beta for this issue.

From @gracenng and sig-release (https://kubernetes.slack.com/archives/C0BP8PW9G/p1689178157530059), I am moving this to a new thread so I can keep the feature up-to-date since I will take over this feature.

#4138 is the new issue.

Thanks @kannon92!

Closing this issue as it is superseded by #4138

/remove-label lead-opted-in

/stage beta
/milestone v1.30

/label lead-opted-in

/milestone clear