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