<div dir="ltr">So looking into the cinder code,<div>  calling attachment_delete should be what we want to call.   But.</div><div><br><div>  I think if we don't have a host connector passed in and the attachment record doesn't have a connector saved,</div><div>then that results in the volume manager not calling the cinder driver to terminate_connection and return.</div><div>This also bypasses the driver's remove_export() which is the last chance for a driver to unexport a volume.</div><div><br></div><div>Walt</div><div></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2019 at 7:27 PM Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Cinderinos,<br>
<br>
I've now got a working patch that migrates legacy volume attachments to <br>
new style v3 attachments [1]. The fun stuff showing it working is in <br>
this paste [2].<br>
<br>
We want to do this data migration in nova because we still have a lot of <br>
compatibility code since Queens for pre-v3 style attachments and we <br>
can't remove that compatibility code (ever) if we don't first make sure <br>
we provide a data migration routine for operators to roll through. So <br>
for example if this lands in Ussuri we can can enforce a nova-status <br>
upgrade check in V and rip out code in X.<br>
<br>
Without digging into the patch, this is the flow:<br>
<br>
1. On nova-compute restart, query the nova DB for instances on the <br>
compute host with legacy volume attachments.<br>
<br>
2. For each of those, create a new style attachment with the host <br>
connector and update the BlockDeviceMapping information in the nova DB <br>
(attachment_id and connection_info).<br>
<br>
3. Delete the existing legacy attachment so when the server is deleted <br>
the volume status goes back to 'available' due to proper attachment <br>
reference counting in the Cinder DB.<br>
<br>
My main question is on #3. Right now I'm calling the v3 attachment <br>
delete API rather than the v2 os-terminate_connection API. Is that <br>
sufficient to cleanup the legacy attachment on the storage backend even <br>
though the connection was created via os-initialize_connection <br>
originally? Looking at the cinder code, attachment_delete hits the <br>
connection terminate code under the covers [3]. So that looks OK. The <br>
only thing I can really think of is if a host connector is not provided <br>
or tracked with the legacy attachment, is that going to cause problems? <br>
Note that I think volume drivers are already required to deal with that <br>
today anyway because of the "local delete" scenario in the compute API <br>
where the compute host that the server is on is down and thus we don't <br>
have a host connector to provide to Cinder to terminate the connection.<br>
<br>
So Cinder people, are you OK with this flow?<br>
<br>
Hello Novaheads,<br>
<br>
Do you have any issues with the above? Note the migration routine is <br>
threaded out on compute start so it doesn't block, similar to the ironic <br>
flavor data migration introduced in Pike.<br>
<br>
One question I have is if we should add a config option for this so <br>
operators can enable/disable it as needed. Note that this requires nova <br>
to be configured with a service user that has the admin role to do this <br>
stuff in cinder since we don't have a user token, similar to nova doing <br>
things with neutron ports without a user token. Testing this with <br>
devstack requires [4]. By default [cinder]/auth_type is None and not <br>
required so by default this migration routine is not going to run so <br>
maybe that is sufficient?<br>
<br>
Hello Operatorites,<br>
<br>
Do you have any issues with what's proposed above?<br>
<br>
[1] <a href="https://review.opendev.org/#/c/549130/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/549130/</a><br>
[2] <a href="http://paste.openstack.org/show/781063/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/781063/</a><br>
[3] <br>
<a href="https://github.com/openstack/cinder/blob/410791580ef60ddb03104bf20766859ed9d78932/cinder/volume/manager.py#L4650" rel="noreferrer" target="_blank">https://github.com/openstack/cinder/blob/410791580ef60ddb03104bf20766859ed9d78932/cinder/volume/manager.py#L4650</a><br>
[4] <a href="https://review.opendev.org/#/c/685488/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/685488/</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
</blockquote></div>