[kubernetes/kubernetes] Deprecate kubelet "enable-controller-attach-detach" option (#55517)
Michelle Au
Is this a BUG REPORT or FEATURE REQUEST?:
/kind feature
@kubernetes/sig-storage-feature-requests
What happened:
Are there any use cases where we still need to support kubelet doing the attach/detach? If not, let's deprecate this field and eventually remove it.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Michelle Au
/remove-lifecycle stale
fejta-bot
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
—
fejta-bot
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale
XsWack
/remove-lifecycle stale
XsWack
according to #20262,
Since rolling upgrades are only supported for up to two Kubernetes releases, after two releases this rolling upgrade logic can be removed. That means the volume.temporary.kubernetes.io/controller-managed annotation can be retirered and the controller can operate on all nodes by default (ignore the annotation).
I think we can remove the logic for kubelet doing the attach/detach.
Jan Šafránek
It's lengthy process to deprecate something. https://kubernetes.io/docs/reference/using-api/deprecation-policy/
With the old policy (when we introduced the annotation), it would fall into
Rule #7: Deprecated behaviors must function for no less than 1 year after their announced deprecation.
But with the new one, it seems impossible to remove the annotation:
The following rules govern the deprecation of elements of the API. This includes:
- Annotations on REST resources, including “beta” annotations but not including “alpha” annotations.
Could we get an exception in this case?
Michelle Au
Discussed with @saad-ali a little, he says there are users that still need this flag so I'm not sure if we can ever remove it. If we cannot remove it and need to support it forever, then maybe we need to at least document the limitations of using this, and test this configuration as well.
Zhuvikin
I think this flag is still needed at least for attach/detach operations in case when some static pod needs volume and controller isn't up yet. My case is to use cinder volume plugin in static pod definition like follows.
volumes:
- cinder:
fsType: "ext4"
volumeID: "1234678-90-1234-5678-90123456789"
name: data
fejta-bot
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
k8s-ci-robot
Closed #55517.
Michelle Au
/reopen
/lifecycle frozen
Kubernetes Prow Robot
Reopened #55517.
Kubernetes Prow Robot
@msau42: Reopened this issue.
In response to this:
/reopen
/lifecycle frozen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Michelle Au
This is an untested configuration and as we're adding more features and designing around AD controller/kubelet coordination for things like migration, this functionality is bound to get broken.
We should think about how to support the static pod scenario outlined above considering the move towards CSI and eventually removing all in-tree plugin code. Many CSI features today depend on K8s api objects and won't work in a static pod/master bootstrapping scenario.
Fabio Bertinatto
@msau42 @jsafrane since we are migrating to CSI and this option is mandatory for that use case, is there a way we can deprecate this now?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are on a team that was mentioned.