The GRPC call to create a volume using another one as source works fine
and creates a cloned volume, but it's not returning the content_source,
so it will pass the csi-sanity tests, but it will fail when running in
Kubernetes because the external-provisioner sidecar expects the field to
be filled.
The reason for the failure is that cinderlib is not setting the right
field when cloning. Instead of setting source_volid it's setting
source_vol_id: https://bugs.launchpad.net/cinderlib/+bug/1849339
The GRPC call to create a volume using another one as source works fine and creates a cloned volume, but it's not returning the content_source, so it will pass the csi-sanity tests, but it will fail when running in Kubernetes because the external-provisioner sidecar expects the field to be filled.
The reason for the failure is that cinderlib is not setting the right field when cloning. Instead of setting source_volid it's setting source_vol_id: https://bugs.launchpad.net/cinderlib/+bug/1849339
There is another cinderlib bug affecting cloning, https://bugs.launchpad.net/cinderlib/+bug/1849828 that prevents us from attaching a volume cloned from an attached volume.
As a temporary workaround we will modify the source code ourselves during installation to fix all these metadata issues.
With this fix we have introduced a new mechanism to run patches when installing ember-csi in our container.