read only volumes should not be expanded and we need OSS ROX testing

[leiyiz]

#972 added unconditional filesystem resize and it should not happen for read only volumes. We are not seeing failures in mounting as resizing RO volume only produce an warning but this could have broken ROX functionality.

1. we should not try to expand RO volumes
2. we should write an OSS ROX test ASAP

[mattcary]

To clarify, it is the filesystem resize that's the problem, not the volume resize?

[judemars]

I'll pick this up, can someone who's a contributor please assign it to me :)

[mattcary]

/assign @judemars

[leiyiz]

To clarify, it is the filesystem resize that's the problem, not the volume resize?

yes, I'll update the issue description

[judemars]

Just a progress update. I think this work will have a few parts:

1. Update mount-utils' resizefs_linux to add a check for readonly bit of filesystem to NeedResize method and return false if so, like so (I made the change directly in the pd repo so you'll have to expand the diff)
2. Update mount-utils package version in pd repo to consume fix from 1) + update resize NodeStageVolume UTs to test resize is skipped if volume is readonly
3. Add ROX k8s integration tests for snapshot, clone, and restore cases. Snapshot and clone will also test that resize is skipped for ROX mode.

I have a couple outstanding questions I'm working through so posting here in case folks have any insight:

1. Updating resizefs in mount_utils will mean that the call to resize in NodeExpandVolume will also be skipped since it calls the same method. Is this okay? It seems like it would have to be since the resize will fail if it's readonly anyways. But as another follow up to that: what happens if the request to NodeExpandVolume has VolumeCapability set to *READER_ONLY? Should we also skip resize in that case?

2. Do we need to update the resize code for windows as well as linux? According to filesystem is not resized when restoring from snapshot/cloning to larger size than origin #972 (comment) it goes through a CSI proxy for the resize instead of doing it directly, but I currently can't find the implementation to be able to check.

[judemars]

Update:
For 1) The mount-utils change is in, need to figure out how/when it gets incorporated into pd-driver repo

For 3) Adding ROX k8s integration tests: go/k8spr/114628 out for review

[judemars]

For 2) it looks like I need to make a change like #1025 to update the version of k8s to 1.27 - @leiyiz (since you did that CL) are we scheduled to upgrade it on some cadence or should I manually do it now?

[mattcary]

For (2) I'd also talk with @mauriciopoppe who has been coordinating windows support.

For (1) we need to update our mount-utils in vendor/. It's a go.mod update, I'll start a discussion on our internal chat as I've been a little fuzzy on this process.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten