On 9/13/2017 9:52 AM, Arne Wiebalck wrote:

On 13 Sep 2017, at 16:52, Matt Riedemann <mriede...@gmail.com> wrote:

On 9/13/2017 3:24 AM, Arne Wiebalck wrote:
I’m reviving this thread to check if the suggestion to address potentially 
stale connection
data by an admin command (or a scheduled task) made it to the planning for one 
of the
upcoming releases?

It hasn't, but we're at the PTG this week so I can throw it on the list of 
topics.


That’d be great, thanks!

--
Arne Wiebalck
CERN IT


We talked about this at the PTG today, notes are in the Cinder etherpad [1], search for "API to refresh volume connection info".

We agreed that we don't need a new admin level API. We are already processing block device info in several operations that involve rebuilding the VM, such as cold migrate/resize, stop/start, suspend/resume, and rebuild. There is a little flag in those code paths which already exists to refresh the connection information for each block device mapping. We agreed to just change those code paths to set that flag to True to refresh the connection information per BDM. We also said we wouldn't fail the operation if the refresh fails for whatever reason, like if Cinder fails. This would not be a backportable change and will have a release note, but it's much more automatic than needing to add an entirely new API. If you want/need to refresh volume connection information without disruption, you'd have to live migrate the server instance.

[1] https://etherpad.openstack.org/p/cinder-ptg-queens

--

Thanks,

Matt

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to