-
Notifications
You must be signed in to change notification settings - Fork 39k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove plugin watching of deprecated directory and CSI v0 support in accordance with deprecation policy #84533
Conversation
69a3f54
to
937e81d
Compare
/retest |
937e81d
to
2f72e43
Compare
/priority backlog |
5efd709
to
5f7802c
Compare
one comment on the way this validates driver versions (I don't think it's wrong as written, but the error could be clearer). lgtm otherwise /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: davidz627, liggitt, msau42 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
0c6897a
to
4e51400
Compare
if isV0Version(version) { | ||
return true | ||
} | ||
if highestSupportedVersion.Major() != 1 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if a driver supports 2.x and 1.x? In the future, if we have a 2.x, the driver Daemonset could theoretically run with a driver that supports both 1.x and 2.x.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we would have to go in and update the validation code. I think the theory is that v2.x
will have breaking changes and we wouldn't want to just "quietly accept" that version in older versions of k8s. If we do decide that older versions of k8s support v2.x+
in the future we can always cherry-pick a relaxation in validation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the driver supports 1.x and 2.x, current versions of kube should allow it and choose to use 1.x, right? does this code do that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh just understood this - yeah fixing. If v2.0 AND v1.0 are supported we should return the highest v1.0 version. Fixing now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, fixed. In the code above it will skip any >v1 versions as a highestSupportedVersion
candidate - so if a driver supports v2.0 and v1.5 the highestSupportedVersion
will be v1.5
…gins and support for CSI V0 in accordance with deprecation announcement in https://v1-13.docs.kubernetes.io/docs/setup/release/notes/
4e51400
to
802fe12
Compare
/retest |
/lgtm |
/hold cancel |
> Note that before Kubernetes v1.17, if the csi socket is in the /var/lib/kubelet/plugins/ path, kubelet may log a lot of harmless errors regarding grpc GetInfo call not implemented (fix in kubernetes/kubernetes#84533). The /var/lib/kubelet/csi-plugins/ path is preferred in Kubernetes versions prior to v1.17. Reference: https://github.com/kubernetes-csi/node-driver-registrar#usage Close: #54
The original deprecation warning said removal in
1.15
; however, this may have been a mistake since this is behavior not a Beta API and thus deprecation policy is actually1 year
which puts it at Kubernetesv1.17
./kind cleanup
/kind documentation
/assign @taragu @saad-ali