Change:
Declared "CSIMigration" feature gate only exists in . According to "CSIMigration" could be a switchable feature gate, but it looks like it is always on and cannot be switched off, so it it's strange that it's mentioned in the v1.27 documentation. All of this is probably more or less OK, as it's suitable for earlier versions of Kubernetes especially since there are deprecation warnings. But it’s also unclear for which components this feature gate is intended. According to it's intended for . <brIt is not clear for which components "CSIMigrationAzureFile" feature gate is intended. <brIt is not clear which controller manager is meant — cloud controller manager or kube-controller-manager. According to it's intended for . It is not clear for which components "CSIMigrationRBD" feature gate is intended: <brIt is not clear for which components "SizeMemoryBackedVolumes" feature gate is intended. <brThe description of "nodeExpandSecretRef" field does not start with a new line in the list. <brThe double word "node".
/language en
/assign RakshitKumar04
Let's stop mentioning in You can specify feature gates for all Kubernetes components (some might be no-ops). We could document that, but it'd be better to track that change as a separate issue. Let's remove the double use of node Let's fix the formatting for these are useful things to point out. Thank you! If you find more, you can help further by opening one issue per thing that will need fixing.
/triage accepted
If you prefer to track this as separate issue, whether I should do something extra or not?
If you're willing to file a separate issue about that clarification please do.
I created separate issue , so this issue should be closed after solving everything except point 2.
Hey, should I raise a PR That fixes the following typos here? The description of "nodeExpandSecretRef" field does not start with a new line in the list. The double word "node". For Linux worker nodes, containerized CSI node node plugins are typically deployed as privileged containers.
If it leads to a documentation fix, sure. Sorry, but I don't know enough about the workflow adopted here. I just feel it is my duty to help make the documentation better and I do my best.
Hey, Should I raise a PR correcting the documentation?

Discussion:
`ControllerPublishVolume` and `ControllerUnpublishVolume` calls. This field is optional, and may be empty if no secret is required. If the Secret contains more than one secret, all secrets are passed. <del> `nodeExpandSecretRef`: A reference to the secret containing sensitive </del> <ins> * `nodeExpandSecretRef`: A reference to the secret containing sensitive </ins> information to pass to the CSI driver to complete the CSI `NodeExpandVolume` call. This field is optional, and may be empty if no secret is required. If the object contains more than one secret, all

CSI node plugins need to perform various privileged operations like scanning of disk devices and mounting of file systems. These operations <del> differ for each host operating system. For Linux worker nodes, containerized CSI node node plugins are typically deployed as privileged containers. For Windows worker nodes, </del> <ins> differ for each host operating system. For Linux worker nodes, containerized CSI node plugins are typically deployed as privileged containers. For Windows worker nodes, </ins> privileged operations for containerized CSI node plugins is supported using [csi-proxy](https://github.com/kubernetes-csi/csi-proxy), a community-managed, stand-alone binary that needs to be pre-installed on each Windows node.