handle volume attachments

[Maxim Korezkij]

I found two block device mappings (bdm) for a volume (mulitattach is off). Also I am not quite sure where the second bdm is coming from. Additionaly one of the bdm has no attachment_id.

When detaching the volume it is possible that nova deletes the wrong attachment, because it assumes that there should be just one attachment when multiattach is turned off (which makes sense).

The fix i propose should prevent the deletion of the attachment when it is unclear how many attachments there are.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/nova/+/833233

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/nova/+/833234

[OpenStack Infra (hudson-openstack)]

Change abandoned by "Maxim Korezkij <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/nova/+/833233

[Stephen Finucane (stephenfinucane)]

Can you provide some kind of logs for this volume so we can understand what's going on? This sounds like a cinder bug

[Maxim Korezkij (maximkorezkij)]

So we saw this log message:

Ignoring exception while attempting to rollback volume connections for volume a6bd064e-bc3b-4eab-81b6-f1c2b81ac9f8 on host cmp123.

Then we checked the bdm in the nova db and the volume attachment in the cinder db.
Then we saw a missmatch between nova and cinder and also realised that there are multiple active attachments on the cinder side, even though the multiattach flag is turned off. After some investigation we didnt find a cause for this issue.

I get your confusion and I/we are also very confused, but we wanted to provide a safe way that if this rare/weird case happens, that it is handled correctly. Also the fix i proposed should not have an impact if everything is working fine.