KEP-5040: Remove gitRepo volume driver. #5039
Conversation
vinayakankugoyal
commented
Jan 14, 2025
•
vinayakankugoyal
commented
- One-line PR description: Initial KEP to remove support for gitRepo volume driver.
- Issue link: Remove gitRepo volume driver. #5040
- Other comments:
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
kind/kep
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: vinayakankugoyal The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
size/XL
k8s-ci-robot
added
the
do-not-merge/work-in-progress
|
Can you open an enhancement issue? Are you planning to target Alpha in 1.33? |
#5040. Yeah we are planning to target Alpha in 1.33 |
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
a7dca39 to
faf4ffe
Compare
vinayakankugoyal
changed the title
|
/ok-to-test |
k8s-ci-robot
added
the
ok-to-test
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
faf4ffe to
b39ccb0
Compare
|
/retest |
vinayakankugoyal
force-pushed
the
gitRepo
branch
from
b39ccb0 to
430203c
Compare
| - We will announce removal in kubernetes release notes, documentation and via | ||
| kubernetes release blog post. | ||
|
|
||
| v1.36 (04/2026): |
There was a problem hiding this comment.
For compat versions, we need 3 versions where the behavior can be made the same wrt toggle. Removing the gate means that it can not be toggled off. This means we need to lock the gate, wait 3 releases, AND THEN we can remove it.
So if we have the gate enableable in 33, 34, 35 and then lock it to off in 36, we need to wait until 39 to actually remove it.
If we lock it in 34, we can remove in 37, but Jordan suggested leaving it toggleable for more than 1 release. So... do we leave it toggleable for 3 releases or 2?
@liggitt ? It's probably fine to leave it for 3, meaning 39 is the removal.
There was a problem hiding this comment.
I think the only bits that are urgent are 1) disabling by default with an escape hatch and 2) starting the process to drive feedback to inform a decision on locking / completely removing.
Once we've disabled by default, I don't especially care if we leave the inert plugin there and opt-in ~forever.
I don't know how long to leave between 1 and 2... enough time that impacted people reach the minor that disables and requires opt-in. I'd guess 2-3 releases.
And yes, remove completely 3 releases after locking.
| maintained. | ||
|
|
||
| ### Alternative 2: Use ValidatingAdmissionPolicy | ||
| We publish a VAP which prevents Pods and other workloads from using gitRepo, and |
There was a problem hiding this comment.
I think we should ALSO do this. Maybe we should propose a new git repo for contributed policies and those sorts of things which work around problems while real fixes are rolling out?
@dims ?
| status: provisional | ||
| creation-date: 2024-12-14 | ||
| reviewers: | ||
| - @thokin |
There was a problem hiding this comment.
I think you can make me the approver along with someone from sig-node -- @SergeyKanzhelev can you nominate someone? Maybe make @saad-ali a reviewer too?
