[openstack-dev] [nova] upgrade connection_info when Ceph mon IP changed

Matt Riedemann mriedem at linux.vnet.ibm.com
Wed May 18 21:18:08 UTC 2016

On 5/18/2016 3:05 PM, melanie witt wrote:
> 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
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I like this idea. Sure it's a delay, but it resolves the problem 
eventually and doesn't add the overhead to the start/reboot operations 
that should mostly be unnecessary if things are working.

I like the short-circuit idea too, although that's a nice to have. A 
deployer can always disable the periodic task if they don't want that 



Matt Riedemann

More information about the OpenStack-dev mailing list