[Bug]: Cannot Update cluster storage size when not bound to a workbench

[diegolovison]

Is there an existing issue for this?

• [X] I have searched the existing issues

Deploy type

Downstream version (eg. RHODS 1.29)

Version

Downstream version - RHODS 1.30.RC3

Current Behavior

Cannot Update cluster storage size when not bound to a workbench

Expected Behavior

A Persistent Volume Claim -> Requested capacity with the value filled in Storage Size

Steps To Reproduce

Create Cluster storage Edit Cluster storage and type a new value for Persistent storage size The value in Volume Claim -> Requested capacity is not changed.

This change is only working if the cluster storage is attached to a workbench

Workaround (if any)

No response

What browsers are you seeing the problem on?

Chrome

Anything else

No response

[DaoDaoNoCode]

I think the k8s is preventing you from updating a pending PVC requested storage unless it's a bound claim. It depends on the storage class we are using and whether it sets volumeBindingMode: Immediate. I think the problem with this issue is we are not showing the error message correctly which is causing confusion to the users. The solution should be correctly showing the error message that's returned by the k8s cluster.

[shalberd]

@andrewballantyne @DaoDaoNoCode There is more to this, I think. Not all storage classes support volume resizing (growing). So it's not just a matter of volumeBindingMode, but also of allowVolumeExpansionfield of the storageClass true or false.

https://stackoverflow.com/questions/67182395/kuberenetes-storageclass-allowvolumeexpansion-how-it-resize-will-work-with-pv-pv

so, having the list of details of cluster storageclasses available might also be useful for this GUI use case in future. i.e. only allow volume expansion (only expansion is allowed, lessening the size is never allowed) if storageclass behind a PVC allows that.

[jstourac]

Hi guys, I can see that this is marked as fixed even though the fix isn't part of the main branch, which is quite confusing.

I can see that the fix is part of the https://github.com/opendatahub-io/odh-dashboard/tree/f/ds-projects branch, is there some issue we could track or some estimation when this gets into the main and thus into the project/product eventually?

[andrewballantyne]

@jstourac PRs merge into a branch, typically f/* or main. Since you noted this was not in main and found the branch (which can find out on the PR itself), you should look for a tracker in this issues links next. All f/* branches are related to trackers in the Dashboard. This tracker is actually the one just above your comment: https://github.com/opendatahub-io/odh-dashboard/issues/1924

Your ETA is this sprint or next sprint depending on if we can get through the sign off process. We are working to close out on long-living feature branches. They were originally just waiting on QE, but given the constraints they were under we never made progress closing out things. We are actively looking to close that gap now.

Hopefully that adds clarity.

[jstourac]

@andrewballantyne, thank you for this info. I was able to find that issue, although since https://github.com/opendatahub-io/odh-dashboard/labels/feature%2Fds-projects showed me quite a bunch of other issues, with 3 trackers, I wasn't sure what's the correct approach here. It was also quite late here so my brain wasn't as sharp as it could be probably.

Thank you for the clarification, Andrew :slightly_smiling_face: