VolumeExpansion ONLINE/OFFLINE capability is not checked

[xing-yang]

When a CSI driver reports PluginCapability_VolumeExpansion_OFFLINE only, external-resizer still calls ControllerExpandVolume when the PVC is used by a Pod.

Instead, the extenal-resizer should check VolumeExpansion plugin capability and only invoke ControllerExpandVolume when PluginCapability_VolumeExpansion_ONLINE is supported by the CSI driver.

[xing-yang]

assign @gnufied

[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

[xing-yang]

/remove-lifecycle stale

[gnufied]

/assign @gnufied

[xing-yang]

/assign @gnufied

[gnufied]

This issue is still on our radar. The reason, we have been hesitant in fixing this is because - any checks we perform in external-resizer to determine if volume is in-use before making controller-expansion call, will be racy.

We can either perform a best-case check in external-resizer but since that will be still subject to races, the plugins must be able to handle such expansion calls and return grpc errors. So volume expansion requests will still be retried, the only difference will be which component returns errors. If external-resizer checks for volume in-use before calling ControllerExpandVolume it will return errors, but if plugin does receive the call (even if volume is in-use), it is the one that will have to return an error.

[xing-yang]

That sounds good. If external-resizer can check if volume is in-use before calling ControllerExpandVolume, that should cover most cases. In the corner case if the call still reaches the plugin, the plugin will return an error.

[gnufied]

Summary of discussion on April 2nd 2020:

We discussed the option of doing a best case check but agreed that - it could worsen the problem where a driver author might falsely (after limited testing) assume that ControllerExpandVolume will not be called if volume is in-use. In the end - driver does need to handle when this happens and return following error as per CSI spec:

| Volume in use | 9 FAILED_PRECONDITION | Indicates that the volume corresponding to the 
specified `volume_id` could not be expanded because it is currently published on a node but the 
plugin does not have ONLINE expansion capability. | Caller SHOULD ensure that volume is not 
published and retry with exponential back off. |

Elsewhere in CSI spec though - SHALL and MUST word is used to describe OFFLINE expansion. I have filed container-storage-interface/spec#423 to discuss this in CSI community meeting.

[gnufied]

Another thing is - even checking resizing condition while doing mount or attach suffers from race conditions that are mentioned in - #62 (comment) so aren't entirely fullproof.

[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

[xing-yang]

This is fixed.

[niladrih]

I think, this behaviour is still present as of kubernetes v1.27.3.