NodeExpand may resize fs for block volume

[msau42]

Looking back at resizer.Resize implementation, it checks the format on the disk before attempting a resize. The problem is, the presence of a filesystem doesn't mean that the PVC is a Filesystem type. A user could mount the volume as Block and manage an ext4/xfs filesystem themselves.

I think fixing this may require adding VolumeCapabilities to the Controller/NodeExpandVolumeRequest

/kind bug
/assign @davidz627
cc @gnufied

[davidz627]

Just to confirm, the intended behavior is:
If the VolumeCapability is Block and the user manages a fs by themselves, we should NOT resize their fs
?

[msau42]

correct

[gnufied]

okay, I have file a bug against CSI for adding the capability - container-storage-interface/spec#380

[gnufied]

Actually I am wondering if we can solve majority of this problem, without making a change in CSI specs. See when volume is of type raw-block the volumePath that you will get with NodeExpandVolume will be a device-path not a mounted file system path. So we can use that information and not perform any file system level expansion when NodeExpandVolume is called on raw block devices.

I think it may still be worth adding capability to NodeExpandVolume and ControllerExpandVolume call but - it will fall under "nice" to have territory and a driver can use this optional information to skip a operation entirely.

[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

[davidz627]

/remove-lifecycle stale

[davidz627]

VolumeCapability was added (container-storage-interface/spec#381) so this should be easy to skip now

[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

[msau42]

/lifecycle frozen

[verult]

VolumeCapabilities are now passed into resize call as part of external-resizer v0.5.0.

[shay-berman]

What is the status of this ticket please?
Looks like it blocking the GA of the GKE CSI driver.

[saad-ali]

/assign

[shay-berman]

Great to see that GA Driver project is all done.
May I ask when the GKE documentation will be update about using the GA driver vs the Beta version?

[msau42]

Once it's completely rolled out in GKE, which will start in rapid channel and eventually reach the stable channel, we will update the GKE documentation. It will take a few weeks to reach stable as it needs to first soak in rapid, then regular channels.

[gnufied]

Did we wanted to expand this functionality and return false from ControllerExpandVolume , if it is called for block volume types? That would eliminate need for calling NodeExpandVolume altogether.

[shay-berman]

@msau42 I am using GKE CSI beta today, just want to make sure. Is there going to be upgrade pass from PVC that were created via the GKE CSI beta to the GAed CSI version?

Do I need to take any action in order to get the CSI GAed version while running on GKE?

Thanks

[msau42]

@shay-berman no changes needed. The GA driver is compatible with the beta. The only action you may need to take is to upgrade your GKE cluster to get the GA driver if you are not on a release channel.