I'm asking that we have the discussion about how to handle these sorts of cases.

I'm asking that we have the discussion about how to handle these sorts of cases.

I have spent almost a year to get kubernetes/enhancements#3857 approved
so as to protect mounts without having a breaking change, and I have notified several times that
I would implement the "Plan B" on the CRI runtimes' side in the case the KEP didn't get interests:

• KEP-3857: Recursive Read-only (RRO) mounts kubernetes/enhancements#3858 (comment)
• Recursive Read-only (RRO) mounts kubernetes/enhancements#3857 (comment)
• https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#heading=h.40lcyqkzkv6x (Jan 16, 2024)

Now I have learnt that this was not enough, and realized a necessity to have some explicit guideline on merging potential breaking changes:

• Guideline for breaking changes project#124

Yep. I am not trying to blame you. We have a KEP that did not get the appropriate attention. We have over-burdened SIGs and maintainers. We have multiple projects with their own policies and stances on what constitutes acceptance risk.

Worst, we have a clear lack of data, which makes it impossible to move forward with any real confidence, so we defaulted to the safe position.

This is not a healthy place to be.

Now what to do with it? I think almost everyone will agree that RRO is a better default. But changing it in the kubernetes-specific corner of containers is not the right fix.

Now what to do with it? I think almost everyone will agree that RRO is a better default. But changing it in the kubernetes-specific corner of containers is not the right fix.

So, this PR reverts:

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

I'll wait again to see if there is any chance to get the KEP approved.
If the KEP fails again, this will be probably reimplemented as a Pod annotation without changing the default.

cc @henry118 @estesp @mikebrow

#9713 was merged on 2024-02-02 and it survived only for a week, so it doesn't affect existing Kubernetes users.

This is being replaced by:

• KEP-3857: Recursive Read-only (RRO) mounts #9787

#9787 doesn't automatically upgrade RO to RRO, and it requires the user to specify recursiveReadOnly mode in the Pod manifest manually.