[nova][cinder][ops] question/confirmation of legacy vol attachment migration
mriedemos at gmail.com
Thu Oct 3 23:22:33 UTC 2019
I've now got a working patch that migrates legacy volume attachments to
new style v3 attachments . The fun stuff showing it working is in
this paste .
We want to do this data migration in nova because we still have a lot of
compatibility code since Queens for pre-v3 style attachments and we
can't remove that compatibility code (ever) if we don't first make sure
we provide a data migration routine for operators to roll through. So
for example if this lands in Ussuri we can can enforce a nova-status
upgrade check in V and rip out code in X.
Without digging into the patch, this is the flow:
1. On nova-compute restart, query the nova DB for instances on the
compute host with legacy volume attachments.
2. For each of those, create a new style attachment with the host
connector and update the BlockDeviceMapping information in the nova DB
(attachment_id and connection_info).
3. Delete the existing legacy attachment so when the server is deleted
the volume status goes back to 'available' due to proper attachment
reference counting in the Cinder DB.
My main question is on #3. Right now I'm calling the v3 attachment
delete API rather than the v2 os-terminate_connection API. Is that
sufficient to cleanup the legacy attachment on the storage backend even
though the connection was created via os-initialize_connection
originally? Looking at the cinder code, attachment_delete hits the
connection terminate code under the covers . So that looks OK. The
only thing I can really think of is if a host connector is not provided
or tracked with the legacy attachment, is that going to cause problems?
Note that I think volume drivers are already required to deal with that
today anyway because of the "local delete" scenario in the compute API
where the compute host that the server is on is down and thus we don't
have a host connector to provide to Cinder to terminate the connection.
So Cinder people, are you OK with this flow?
Do you have any issues with the above? Note the migration routine is
threaded out on compute start so it doesn't block, similar to the ironic
flavor data migration introduced in Pike.
One question I have is if we should add a config option for this so
operators can enable/disable it as needed. Note that this requires nova
to be configured with a service user that has the admin role to do this
stuff in cinder since we don't have a user token, similar to nova doing
things with neutron ports without a user token. Testing this with
devstack requires . By default [cinder]/auth_type is None and not
required so by default this migration routine is not going to run so
maybe that is sufficient?
Do you have any issues with what's proposed above?
More information about the openstack-discuss