Open Stack

Nova stores the output of the Cinder os-initialize_connection info API 
in the Nova block_device_mappings table, and uses that later for making 
volume connections.

This data can get out of whack or need to be refreshed, like if your 
ceph server IP changes, or you need to recycle some secret uuid for your 
ceph cluster.

I think the only ways to do this on the nova side today are via volume 
detach/re-attach, reboot, migrations, etc - all of which, except live 
migration, are disruptive to the running guest.

I've kicked around the idea of adding some sort of admin API interface 
for refreshing the BDM.connection_info on-demand if needed by an 
operator. Does anyone see value in this? Are operators doing stuff like 
this already, but maybe via direct DB updates?

We could have something in the compute API which calls down to the 
compute for an instance and has it refresh the connection_info from 
Cinder and updates the BDM table in the nova DB. It could be an admin 
action API, or part of the os-server-external-events API, like what we 
have for the 'network-changed' event sent from Neutron which nova uses 
to refresh the network info cache.

Other ideas or feedback here?

-- 

Thanks,

Matt