Looked a bit deeper and I can confirm that the issue is because cinder's state machine does not allow two parallel attachment creation even for a multiattach volume. There are transitional states like reserved, attaching where cinder rejected the new attachment create. As these are transitional states on way to fix this is to retry from the client (nova) side. A similar issue[1] was reported on glance when glance is acting as a client for cinder (as it uses cinder as the backend for image storage). There the fix was to add a retry mechanism to the glance code. Based on the discussion in [2][3] I don't think cinder is willing to relax the state machine rules for the multiattach volumes. So we should also consider adding a retry loop in nova to fix this.
I marking this as triaged as it is a real problem but we see a way forward. Feel free to propose a patch adding the retry loop.
Looked a bit deeper and I can confirm that the issue is because cinder's state machine does not allow two parallel attachment creation even for a multiattach volume. There are transitional states like reserved, attaching where cinder rejected the new attachment create. As these are transitional states on way to fix this is to retry from the client (nova) side. A similar issue[1] was reported on glance when glance is acting as a client for cinder (as it uses cinder as the backend for image storage). There the fix was to add a retry mechanism to the glance code. Based on the discussion in [2][3] I don't think cinder is willing to relax the state machine rules for the multiattach volumes. So we should also consider adding a retry loop in nova to fix this.
I marking this as triaged as it is a real problem but we see a way forward. Feel free to propose a patch adding the retry loop.
[1] https:/ /bugs.launchpad .net/glance- store/+ bug/1969373 /meetings. opendev. org/meetings/ cinder_ bs/2022/ cinder_ bs.2022- 04-13-15. 02.log. html#l- 39 /bugs.launchpad .net/cinder/ +bug/1940466
[2] https:/
[3] https:/