> In any case I strongly believe that nova should never proceed to delete the cinder attachment if detaching with os-brick fails because that usually implies data loss.
> The exception would be when the cinder volume is going to be delete after disconnecting it, and in that case the disconnect call to os-brick should be always forced, since data loss is irrelevant.
> That would ensure that compute nodes are not left with leftover devices that could cause problems.
Understood. I guess that must mean that the reported bug scenario is a volume that is *not* delete_on_termination=True attached to an instance that is being deleted.
I think we could probably propose a patch in nova to not delete the attachment if it's instance delete + not delete_on_termination.
> In any case I strongly believe that nova should never proceed to delete the cinder attachment if detaching with os-brick fails because that usually implies data loss.
> The exception would be when the cinder volume is going to be delete after disconnecting it, and in that case the disconnect call to os-brick should be always forced, since data loss is irrelevant.
> That would ensure that compute nodes are not left with leftover devices that could cause problems.
Understood. I guess that must mean that the reported bug scenario is a volume that is *not* delete_ on_termination= True attached to an instance that is being deleted.
I think we could probably propose a patch in nova to not delete the attachment if it's instance delete + not delete_ on_termination.