Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
We explicitly made a choice to not skip
NodeExpandVolumeif volume type is of block type. The reasoning is - the spec does not stipulate thatNodeExpandVolumewill not be called if volume is of block type. Only a plugin can decide whetherNodeExpandVolumecan be skipped or not.This is pending on a fix in kubelet - kubernetes/kubernetes#79990 too.
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.
Okay, I still think there is a fix to be made here, to not put FileSystemResizePending & FileSystemResizeRequired on block volumes. NodeExpand can still be called but the user-facing things should be accurate
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.
Yeah I think the naming of conditions is bit wrong and pre-dates CSI spec . I will look into renaming those conditions to be more accurate.
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.
Hm, how on the plugin side can I decide whether to skip NodeExpandVolume? When it's called, I only get volume ID and path, it doesn't tell me if the CO intends for the volume to be used as block or not. If it's block, I'd like to no-op.
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.
ControllerExpandVolume won't know if the volume is block or not either, so it can't return false for node expansion required
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 thought pd driver skipped NodeExpand based on volume capability but I was wrong: kubernetes-sigs/gcp-compute-persistent-disk-csi-driver#372
cc @davidz627
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 I am in favour of adding supplying volume capabilities into both
ControllerExpandVolumeandNodeExpandVolume.NodeExpandVolumehas a clear use case where we might not want to fs resize the volume even if it has file system on it - if volume is being used in block mode.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.
This is a similar change to the one I made during resize migration: #39 (comment)
If we want SP to decide if to do
NodeExpandVolume, not sure if we still need this change here