Open Stack

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