/sig node

adding sig storage as participating sig

/sig storage

@AkihiroSuda do you want to target this KEP for 1.28?

@AkihiroSuda do you want to target this KEP for 1.28?

Not necessary.

@kubernetes/sig-node-leads
Any chance to get this lead-opted-in for v1.29?

ping @kubernetes/sig-node-leads 🙏

@kubernetes/sig-node-leads
Will this be considered for lead-opted-in in the v1.30 milestone?

cc @mrunalp @derekwaynecarr @dchen1107 @SergeyKanzhelev for the question above about v1.30 milestone

+1 for v1.30

• We may tag this as v1.30 and get some early input.

adding sig storage as participating sig

@SergeyKanzhelev do we have to check with sig storage leads about this KEP?

@mrunalp @derekwaynecarr @dchen1107 @SergeyKanzhelev

PTAL.
If this KEP isn't going to be accepted, I'll just modify the default behavior of containerd to treat "readonly" as "recursive readonly".
Small portion of users may find this to be a breaking change, but probably this is subtle enough.
#3858 (comment)

@SergeyKanzhelev added sig storage as participating sig for this KEP. The proposal makes sense to me, but I still want to hear from the sig storage members. cc @jsafrane @msau42 @xing-yang Can you please review the proposal and provide your feedback? Thanks! If accepted, this KEP may be able to have an alpha implement in 1.30.

Didn't get lead-opted-in. Giving up.

Alternative:

• [Reverted in #9747] cri: make read-only mounts recursively read-only containerd/containerd#9713

Reopening

#3858 (comment)

/milestone 1.30
/stage alpha
/label lead-opted-in

@mrunalp: The provided milestone is not valid for this repository. Milestones in this repository: [v1.25, v1.27, v1.28, v1.29, v1.30, v1.31]

Use /milestone clear to clear the milestone.

Proposal: promote to GA

* [KEP-3857: Recursive Read-only (RRO) mounts: promote to GA #5157](https://github.com/kubernetes/enhancements/pull/5157)

I'll take a look from PRR perspective, but you need to ping sig-node leads to get this included in 1.33 release, it is not currently.

ping @kubernetes/sig-node-leads

/label lead-opted-in
/milestone v1.33

Hello @AkihiroSuda 👋, v1.33 Enhancements team here.

Just checking in as we approach enhancements freeze on 02:00 UTC Friday 14th February 2025 / 19:00 PDT Thursday 13th February 2025.

This enhancement is targeting stage stable for v1.33 (correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP readme using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable for latest-milestone: v1.33.
• KEP readme has up-to-date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements. (For more information on the PRR process, check here). If your production readiness review is not completed yet, please make sure to fill the production readiness questionnaire in your KEP by the PRR Freeze deadline on Thursday 6th February 2025 so that the PRR team has enough time to review your KEP.

For this KEP, we would just need to update the following:

• In the kep.yaml, the latest-milestone needs to be updated to v1.33
• In the PRR file, an approver for stable needs to be listed. Once your PR merges, both of these should be resolved.

The status of this enhancement is marked as At risk for enhancements freeze. Please keep the issue description up-to-date with appropriate stages as well.

If you anticipate missing enhancements freeze, you can file an exception request in advance. Thank you!

Hello @AkihiroSuda 👋, v1.33 Enhancements team here.

With all the requirements fulfilled, this enhancement is now marked as tracked for the upcoming enhancements freeze 🚀

Hello @AkihiroSuda 👋, v1.33 Docs Lead here.

Does this enhancement work planned for v1.33 require any new docs or modification to existing docs?

If so, please follow the steps here to open a PR against dev-1.33 branch in the k/website repo. This PR can be just a placeholder at this time and must be created before Thursday 27th February 2025 18:00 PDT.

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

Thank you!

Docs

Here:

• KEP-3857: Recursive Read-only (RRO) mounts: promote to GA website#49866

Thanks @AkihiroSuda

Hi @AkihiroSuda 👋 -- this is Ryota (@rytswd) from the 1.33 Communications Team!

For the 1.33 release, we are currently in the process of collecting and curating a list of potential feature blogs, and we'd love for you to consider writing one for your enhancement!

Although you have kindly written a feature blog for 1.30 already, would you be keen to get another blog write-up for this making the stable release?

To opt in to write a feature blog, could you please let us know and open a "Feature Blog placeholder PR" (which can be only a skeleton at first) against the website repository by Wednesday, 5th March, 2025? For more information about writing a blog, please find the blog contribution guidelines 📚

Hi @AkihiroSuda 👋, 1.33 Communications Team here again!

This is a gentle reminder for the feature blog deadline mentioned above, which is 02:00 UTC Wednesday, 5th March, 2025. To opt in, please let us know and open a Feature Blog placeholder PR against k/website by the deadline. If you have any questions, please feel free to reach out to us!

Hey again @AkihiroSuda 👋, v1.33 Enhancements team here.

Just checking in as we approach code freeze at 02:00 UTC Friday 21st March 2025 / 19:00 PDT Thursday 20th March 2025.

Here's where this enhancement currently stands:

• 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 ready to be merged (they have approved and lgtm labels applied) by the code freeze deadline. This includes tests.

Per the issue description, these are all of the implementation (code-related) PRs for 1.33:

• KEP-3857: Recursive Read-only (RRO) mounts: promote to GA kubernetes#130116

Please let me know (and keep the issue description updated) if there are any other PRs in k/k that we should track for this KEP, so that we can maintain accurate status.

This enhancement is now marked as Tracked for code freeze for the v1.33 Code Freeze!

Please note that KEPs targeting stable need to have the status field marked as implemented in the kep.yaml file after code PRs are merged and the feature gates are removed.

Completed

/reopen

I think we should keep this open as a reminder that after 3 releases we can drop the feature gates.

@kannon92: Reopened this issue.

/stage stable