-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Track Additional Comments for ModifyVolume in KEP-3751 #549
Comments
There is an other thing that I would lke to see considered for From me:
And a more detailed example from @jdef:
The NFS-server hostname change is one example that should be very clear. Without unmounting and remounting the NFS-export the modified parameter (hostname) can not be applied, and the volume will keep using the original value. Unmounting is not possible if a workload is actively using the volume, so a restart of the container(s) with NodeUnstage/NodeStage (and/or Publish) is required. For Ceph-CSI, an other realistic problem is configuration of IOPS/throughput. This needs to be configured client-side while attaching the volume (during As the requirement to re-attach the volume depends on the modified parameter(s), a hint in |
Yes above make sense for the RBD CSI driver, we support both krbd and nbd to mount the volumes, for volumes mounted with krbd needs to be reattached when the IOPS value changes as the IOPS is set on the device mounted on the node, and some indication need to be set to the csi plugin on the node to change the value. We handle the volumes attached with nbd differently by setting at the ceph. It would be good to return an indication from the Controller that Node operation is required for volume as we do for the Expansion workflow. |
@nixpanic NodeModifyVolume is not included in this KEP proposal. Resize API and this ModifyVolume API is two separate APIs. Are you suggesting us to consider some consecutive operations for Resizing and ControllerModifyVolume? |
Hi @sunnylovestiramisu , yes, I understand those are different operations. For some Storage Providers, some of the options that are modifiable, the currently staged/published volume will use options until it is staged/published anew. If an option requires newly staging/publishing, the controller should be able to inform the CO about that, so that appropriate actions can be taken. The CO could log the requirement so that an admin can restart the workload at a convenient time, or the CO could even stop/start a workload by itself. A hint in the
Taking this a little further, writing this while not having considered it earlier... There may be Storage Providers that require a workload to be inactive while an option is modified. In that case |
This probably needs a discussion among the larger crowd. And is it possible to implement node operations later as a followup P2 and we make sure it is extensible? Basically P0/P1 in this KEP will enable the modification function to the providers that only needs the controller operation, P2 enable providers that needs both. We need to collect use case from all providers that need or will need the node operation first to propose a solution. Referring to the ControllerExpandVolume API, the signal it gives about if a node operation is needed is using a node_expansion_required field to signal if there is further operation needed on the node. But the proposal here is more complicated than a bool and more states involved. |
Is your feature request related to a problem?/Why is this needed
There are some final discussions around the exact wording of the Spec in #544, this issue is created to track those comments and revisit before the changes go to Beta.
Describe the solution you'd like in detail
Describe alternatives you've considered
N/A
Additional context
Issue in Kubernetes is in kubernetes/enhancements#3780
The text was updated successfully, but these errors were encountered: