Use CSI spec v1.5.0

[chrishenzie]

What type of PR is this?
/kind feature

What this PR does / why we need it:
Updates the CSI spec version to v1.5.0, which includes support for SINGLE_NODE_SINGLE_WRITER and SINGLE_NODE_MULTI_WRITER access modes.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

Updates container-storage-interface dependency to v1.5.0

[chrishenzie]

/assign @msau42
/assign @bswartz

[xing-yang]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: chrishenzie, xing-yang

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:

• OWNERS [xing-yang]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[chrishenzie]

/remove-kind feature
/kind cleanup

[chrishenzie]

Relabeling, categorizing this as a feature for this sidecar because it enables new functionality.

/remove-kind cleanup
/kind feature

[pohly]

Relabeling, categorizing this as a feature for this sidecar because it enables new functionality.

Which functionality is that?

I don't see any code changes that depend on the new CSI version.

[chrishenzie]

Enabling the use of the new CSI access modes. These are used here to map between Kubernetes and CSI access modes:
https://github.com/kubernetes-csi/external-attacher/blob/v3.3.0/vendor/github.com/kubernetes-csi/csi-lib-utils/accessmodes/access_modes.go

Which is used here inside the attacher:
https://github.com/kubernetes-csi/external-attacher/blob/v3.3.0/pkg/controller/util.go#L175

[pohly]

But "enabling the use" is not the same as "using". Unless I am missing something, this PR causes no functional change in external-attacher. That will change in a future PR where the new definitions from CSI 1.5 are actually used.

[chrishenzie]

I think because I'm retroactively fixing the label on this PR it's easy to get the tenses confused. This new access mode code is now in use, but at the time of this PR it was not.

I have been labeling PRs that update dependencies across sidecars as feature if that code will be exercised as part of a future feature, that way readers can see both the dependency bump and feature addition (the mapping logic) in the same section of the changelog since the feature is dependent on the dependency bump.

If you don't think this is an appropriate use of this label I can change this going forward. What label would you suggest instead? cleanup? Alternatively I can package dependency bumps with the specific feature, however in the past I've received feedback to handle these separately. Or I can not tag these at all.

[pohly]

I think because I'm retroactively fixing the label on this PR it's easy to get the tenses confused. This new access mode code is now in use, but at the time of this PR it was not.

Then the PR which put that new access mode into use should be marked as "feature", but not this PR here. Look at it from the perspective of a user who sees a new feature listed in the changelog with a link to this PR here: there's simple nothing here that explains what that new feature is.

If you don't think this is an appropriate use of this label I can change this going forward. What label would you suggest instead? cleanup?

I would use cleanup and only use feature or bug if that update is known to enable new features or fix some bug, in which case the change note should mention those and not just "update foo to x.y.z".

Alternatively I can package dependency bumps with the specific feature, however in the past I've received feedback to handle these separately.

A separate PR is useful because typically we want to merge dependency updates regardless of whether the new feature gets merged.