Open Stack

On Wed, 18 May 2016 14:30:00 -0500, Matt Riedemann wrote:
> While convenient as a workaround, I'm not in favor of the idea of adding
> something to the REST API so a user can force refresh the connection
> info - this is a bug and leaks information out of the API about how the
> cloud is configured. If you didn't have volumes attached to the instance
> at all then this wouldn't matter.
>
> I think in an earlier version of the patch it was reloading and checking
> the connection info every time the BDM list was retrieved for an
> instance, which was a major issue for normal operations where this isn't
> a problem.
>
> Since it's been scoped to just start/reboot operations, it's better, and
> there are comments in the patch to make it a bit more efficient also
> (avoid calling the DB multiple times for the same information).
>
> I'm not totally opposed to doing the refresh on start/reboot. We could
> make it configurable, so if you're using a storage server backend where
> the IP might change, then set this flag, but that's a bit clunky. And a
> periodic task wouldn't help us out.
>
> I'm open to other ideas if anyone has them.


I was thinking it may be possible to do something similar to how network 
info is periodically refreshed in _heal_instance_info_cache [1]. The 
task interval is configurable (defaults to 60 seconds) and works on a 
queue of instances such that one is refreshed per period, to control the 
load on the host. To avoid doing anything for storage backends that 
can't change IP, maybe we could make the task return immediately after 
calling a driver method that would indicate whether the storage backend 
can be affected by an IP change.

There would be some delay until the task runs on an affected instance, 
though.

-melanie


[1] 
https://github.com/openstack/nova/blob/9a05d38/nova/compute/manager.py#L5549