So far I have been able to identify 3 different ways to create similar situations to the reported one, and it was what I thought, leftover devices from a 'nova delete' call.
Took me longer to figure it out because it requires an iSCSI Cinder driver that uses shared targets, and the one I use doesn't.
After I locally modified the cinder driver code to do target sharing and then force a disconnect error on specific Nova calls to os-brick I was able to work it out.
I have a local patch that detects these issues and fixes them the best it can, but I wouldn't like to backport that, because the fixing is a bit scary as a backport.
So I'll split the code into 2 patches:
- The backportable patch that detects and prevents the connection if a potential leak is detected. To fix this manual intervention will be necessary.
- Another patch that extends the previous code to try to fix things when possible.
I have finally been able to reproduce the issue.
So far I have been able to identify 3 different ways to create similar situations to the reported one, and it was what I thought, leftover devices from a 'nova delete' call.
Took me longer to figure it out because it requires an iSCSI Cinder driver that uses shared targets, and the one I use doesn't.
After I locally modified the cinder driver code to do target sharing and then force a disconnect error on specific Nova calls to os-brick I was able to work it out.
I have a local patch that detects these issues and fixes them the best it can, but I wouldn't like to backport that, because the fixing is a bit scary as a backport.
So I'll split the code into 2 patches:
- The backportable patch that detects and prevents the connection if a potential leak is detected. To fix this manual intervention will be necessary.
- Another patch that extends the previous code to try to fix things when possible.