On 10/4/2019 11:03 AM, Walter Boring wrote:
I think if we don't have a host connector passed in and the attachment record doesn't have a connector saved, then that results in the volume manager not calling the cinder driver to terminate_connection and return. This also bypasses the driver's remove_export() which is the last chance for a driver to unexport a volume.
Two things: 1. Yeah if the existing legacy attachment record doesn't have a connector I was worried about not properly cleaning on for that old connection, which is something I mentioned before, but also as mentioned we potentially have that case when a server is deleted and we can't get to the compute host to get the host connector, right? 2. If I were to use os-terminate_connection, I seem to have a tricky situation on the migration flow because right now I'm doing: a) create new attachment with host connector b) complete new attachment (put the volume back to in-use status) - if this fails I attempt to delete the new attachment c) delete the legacy attachment - I intentionally left this until the end to make sure (a) and (b) were successful. If I change (c) to be os-terminate_connection, will that screw up the accounting on the attachment created in (a)? If I did the terminate_connection first (before creating a new attachment), could that leave a window of time where the volume is shown as not attached/in-use? Maybe not since it's not the begin_detaching/os-detach API...I'm fuzzy on the cinder volume state machine here. Or maybe the flow would become: a) create new attachment with host connector b) terminate the connection for the legacy attachment - if this fails, delete the new attachment created in (a) c) complete the new attachment created in (a) - if this fails...? Without digging into the flow of a cold or live migration I want to say that's closer to what we do there, e.g. initialize_connection for the new host, terminate_connection for the old host, complete the new attachment. -- Thanks, Matt