Closed sunnylovestiramisu closed 8 months ago
make test succeeded locally, but the presubmit jobs failed with:
go: go.mod file indicates go 1.21, but maximum version supported by tidy is 1.20
ERROR: vendor check failed.
make: *** [release-tools/build.make:279: test-vendor] Error 1
/assign @gnufied
The current implementation of the VolumeAttributesClass feature re-uses the workflow of volume resize controller. We have to take care of the following issues:
I am not sure if this is the best approach. I would like to discuss this topic here.
The volume resize controller should be used only for volume resize. I think that the VolumeAttributesClass feature should be implemented as a separate workflow. In other words, implement a new controller for the VolumeAttributesClass feature. The new controller codes can be placed in the external-resizer repository to avoid introducing a new sidecar container.
The volume resize controller should be used only for volume resize <-- we are putting it here because we do not want to add another sidecar to maintain. So we do not want to have a new controller. This has been discussed a few time during design sessions. If there is new points you want to make we can revisit.
About having a new controller, I am neutral on this. Let's see what others say.
Okay talked with Michelle, her words are "we are trying to consolidate components. It is too much of maintenance burden to manage so many. kube-controller-manager contains many controllers all in one process."
Have we done an e2e test (and by e2e here I mean manual testing) of this PR? No we haven't, we need a csi driver actually implement this feature to test end to end. And right now no csi driver implemented it.
Have we done an e2e test (and by e2e here I mean manual testing) of this PR? No we haven't, we need a csi driver actually implement this feature to test end to end. And right now no csi driver implemented it.
I am afraid, we shouldn't merge this feature without testing the entire workflow with either mock driver or something similar.
@gnufied we have mock driver unit tests in each sidecars though, just not together. What did you do for other resizer features in the past?
Okay I talked with Michelle, the end to end testing does not need to be in an actual provider's driver, we can use csi-driver-host-path.
Let's add the test cases in: https://github.com/kubernetes-csi/csi-driver-host-path/issues/479
What did you do for other resizer features in the past?
We tested the entire workflow e2e using either mock or hostpath driver. It will be very unusual to ship a feature without working through entire workflow.
Okay talked with Michelle, her words are "we are trying to consolidate components. It is too much of maintenance burden to manage so many. kube-controller-manager contains many controllers all in one process."
I am sort of leaning towards what @carlory proposed here and while having a entirely new sidecar indeed will be bad, but having just a simple control-loop is not so bad. We already have examples of simple control-loops in KCM such as for PVC protection etc. @msau42 what do you think?
Currently - putting both VAC modification and volume resizing kinda tramples over each other's state. For example - if there is an error while modifying volume, then resizing can't happen as well because control will return from the loop. We will avoid these problems if we chose to keep a separate controller.
Also things like retry rate for resizing could be different for retry rate for volume modification. All these things are hard to control in single control loop for same PVC.
Also add in the release note that this requires the feature gate in resizer to be enabled, and the feature gate and api to be enabled in the k8s cluster.
Also add the feature here: https://github.com/kubernetes-csi/external-resizer?tab=readme-ov-file#feature-status
Changed the release note and also added the feature to README.md
Thanks for the release note, can you add the specific feature gate and API that have to be enabled?
I added VolumeAttributesClass feature gate to the description.
Also retested the code end to end:
k describe pvc
Name: csi-pvc
Namespace: default
StorageClass: csi-hostpath-sc
Status: Bound
Volume: pvc-eb5c043c-d60f-4b38-92b5-9d581eb97c7e
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
volume.beta.kubernetes.io/storage-provisioner: hostpath.csi.k8s.io
volume.kubernetes.io/storage-provisioner: hostpath.csi.k8s.io
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 1Gi
Access Modes: RWO
VolumeMode: Filesystem
Used By: my-csi-app
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ExternalProvisioning 6m16s persistentvolume-controller Waiting for a volume to be created either by the external provisioner 'hostpath.csi.k8s.io' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.
Normal Provisioning 6m16s hostpath.csi.k8s.io_csi-hostpathplugin-0_49e258d5-2317-4bba-94e8-24fc5c72b4aa External provisioner is provisioning volume for claim "default/csi-pvc"
Normal ProvisioningSucceeded 6m16s hostpath.csi.k8s.io_csi-hostpathplugin-0_49e258d5-2317-4bba-94e8-24fc5c72b4aa Successfully provisioned volume pvc-eb5c043c-d60f-4b38-92b5-9d581eb97c7e
Normal VolumeModify 99s external-resizer hostpath.csi.k8s.io external resizer is modifying volume csi-pvc with vac silver
Normal VolumeModifySuccessful 99s external-resizer hostpath.csi.k8s.io external resizer modified volume csi-pvc with vac silver successfully
Normal VolumeModify 4s external-resizer hostpath.csi.k8s.io external resizer is modifying volume csi-pvc with vac gold
Normal VolumeModifySuccessful 4s external-resizer hostpath.csi.k8s.io external resizer modified volume csi-pvc with vac gold successfully
Can you squash the commits?
@gnufied Rebased and combined all the commits into one :)
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: gnufied, sunnylovestiramisu
The full list of commands accepted by this bot can be found here.
The pull request process is described here
/kind feature
What this PR does / why we need it: Implement logic of this diagram
Which issue(s) this PR fixes:
Fixes https://github.com/kubernetes-csi/external-resizer/issues/314
Special notes for your reviewer:
Testing Steps
Positive Test Cases
kubectl edit pvc csi-pvc
and addvolumeAttributesClassName: silver
to the pvcgold
and applykubectl edit pvc csi-pvc
and addvolumeAttributesClassName: gold
to the pvcNegative Test Cases
Verify in the log via
k logs csi-hostpathplugin-0 csi-resizer
, and the log print out:The
===== Check if VolumeAttributesClass is Enabled =====
shows that VAC is not enabled and the resizer is up and running without initializing the modify controller, please see the logs print out setting here.Does this PR introduce a user-facing change?: