The peerpod volume custom resource is currently only created during the CreateVolume rpc of the controller service.
This endpoint is called by Kubernetes during the creation of a persistent volume claim (PVC) without an already existing persistent volume (PV).
All subsequent controller, node, and podvm csi-wrapper endpoints that interact with peerpod volumes CRs (e.g. ControllerPublishVolume) now assume that a peerpod volume already exists.
However, this is not the case if a PVC with a manually created, or already existing, PV is created.
This is required when statically provisioning a volume, for example, by the azuredisk-csi-driver to consume a pre-existing disk through a PVC.
When a PV already exists, the CreateVolume endpoint is never called, and we directly go to ControllerPublishVolume instead.
This PR aims to fix this problem by performing an check during ControllerPublishVolume if there is no matching peerpod volume found.
Since the information we get during ControllerPublishVolume is a lot more limited than what we get during CreateVolume, a little workaround is needed.
Mainly, we don't have access to the Parameters field of the PVC, which we use during CreateVolume to discern if a peerpod volume should be created, by checking if it contains the key peerpod.
So instead, we rely on the user to set the peerpod key in the VolumeContext field of the manually created PV.
A second issue is that we don't have access to the VolumeName of the PVC during ControllerPublishVolume.
This value is checked for comparison during NodePublishVolume to ensure the peerpod volume matches the "real" volume to publish.
We side steps this issue by setting a placeholder name during ControllerPublishVolume, and if this placeholder is set during NodePublishVolume, replace it with the real value.
The peerpod volume custom resource is currently only created during the
CreateVolume
rpc of the controller service. This endpoint is called by Kubernetes during the creation of a persistent volume claim (PVC) without an already existing persistent volume (PV). All subsequent controller, node, and podvm csi-wrapper endpoints that interact with peerpod volumes CRs (e.g.ControllerPublishVolume
) now assume that a peerpod volume already exists.However, this is not the case if a PVC with a manually created, or already existing, PV is created. This is required when statically provisioning a volume, for example, by the azuredisk-csi-driver to consume a pre-existing disk through a PVC. When a PV already exists, the
CreateVolume
endpoint is never called, and we directly go toControllerPublishVolume
instead.This PR aims to fix this problem by performing an check during
ControllerPublishVolume
if there is no matching peerpod volume found. Since the information we get duringControllerPublishVolume
is a lot more limited than what we get duringCreateVolume
, a little workaround is needed. Mainly, we don't have access to theParameters
field of the PVC, which we use duringCreateVolume
to discern if a peerpod volume should be created, by checking if it contains the keypeerpod
. So instead, we rely on the user to set thepeerpod
key in theVolumeContext
field of the manually created PV.A second issue is that we don't have access to the
VolumeName
of the PVC duringControllerPublishVolume
. This value is checked for comparison duringNodePublishVolume
to ensure the peerpod volume matches the "real" volume to publish. We side steps this issue by setting a placeholder name duringControllerPublishVolume
, and if this placeholder is set duringNodePublishVolume
, replace it with the real value.