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

Rajesh Tailor ratailor at redhat.com
Thu Mar 2 13:22:13 UTC 2017

>n 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]
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at
>> 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

Hi Matt,

I was thinking, if it could be done on restarting of nova-compute service.
Because if operator is going to change storage node IPs, they might need to
restart at least some services, so we can ask operator to restart
nova-compute service as well, if instances on that compute-node is going to
be affected by IP change.

To fix this issue, we can hard reboot the affected instances on restart of
nova-compute service, by doing so the updated connection info is getting
stored in BDM table as well as recorded in domain xml.

Please correct me if I am wrong.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170302/c3fdb3eb/attachment.html>

More information about the OpenStack-dev mailing list