Add volume health proposal

[gnufied]

No description provided.

[nixpanic]

I wondered if removing the volume_condition field (and others) causes compatibility issues. It seems that using the reserved notation addresses my concerns.

👍

[nixpanic]

This is actually something that could be provided by the controller too. Network storage clusters (like Ceph) can return their health with sufficient parameters and secrets. If the backend storage is unhealthy, there probably is little reason to attempt to use it for new volumes, or expect (fully) functional usage by the nodeplugin.

[gnufied]

I was thinking about this use case, but where would we report it? In CSIDriver object? I do not think, CSI driver object was designed for such use case, but idea is sound in theory.

I am intentionally keeping some of the health reporting as future enhancement, so as we can ship something rather than being bogged down by designing everything upfront. I am adding a section in kubernetes/enhancements#6138 to keep track of future enhancements. I will update

[nixpanic]

I was thinking about this use case, but where would we report it? In `CSIDriver` object? I do not think, CSI driver object was designed for such use case, but idea is sound in theory. I am intentionally keeping some of the health reporting as future enhancement, so as we can ship something rather than being bogged down by designing everything upfront. I am adding a section in kubernetes/enhancements#6138 to keep track of future enhancements. I will update

Thanks for the consideration. There is no need to include such a feature with this PR, but it would be nice if we can add it at a later time. The (currently) only location where this makes sense to report, is at the StorageClass level. Depending on the parameters/secrets, a part of a storage backend could be unhealthy (like a pool of disks, HDD vs NVMe, or network connection type, or the like).