Add volume health proposal#604
Conversation
gnufied
force-pushed
the
implement-volume-health
branch
2 times, most recently
from
ee77999 to
8789044
Compare
gnufied
force-pushed
the
implement-volume-health
branch
from
8789044 to
456214c
Compare
| message NodeGetStorageHealthResponse { | ||
| option (alpha_message) = true; | ||
|
|
||
| message StorageBackendHealth { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
|
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).
|
nixpanic
left a comment
nixpanic
left a comment
There was a problem hiding this comment.
The current proposal looks good to me, and it should be workable with the CSI-drivers for Ceph.
| // The storage backend is operating in a degraded | ||
| // state (e.g. reduced path count, high latency). | ||
| // Volumes using this backend may experience reduced performance. | ||
| STORAGE_DEGRADED = 2; |
There was a problem hiding this comment.
Can we reuse the enum we defined for VolumeHealth here ?
There was a problem hiding this comment.
@bswartz I have been thinking long and hard about this and IMO keeping these two enum separate makes most sense in the long run. If we chose one enum, we will have to overload the semantics, the expected CO behaviour for node vs single volume could be different.
| // Secrets required by the plugin to complete the request. | ||
| // This field is OPTIONAL. Refer to the `Secrets Requirements` | ||
| // section on how to use this field. | ||
| map<string, string> secrets = 1 [(csi_secret) = true]; |
There was a problem hiding this comment.
Where will this be coming from? Where will this be stored in k8s?
There was a problem hiding this comment.
We discussed this some more in CSI implementation meeting and we are keeping these secret fields, but in current iteration of k8s implementation, secrets will be unsupported for volume health. The exact details for where the secret for these health RPCs will be coming in k8s will be decided later.
3 participants
No description provided.