<div dir="ltr"><div><div><div><div>>n Wed, 18 May 2016 14:30:00 -0500, Matt Riedemann wrote:<br>>>> While convenient as a workaround, I'm not in favor of the idea of adding<br>>>> something to the REST API so a user can force refresh the connection<br>>>> info - this is a bug and leaks information out of the API about how the<br>>>> cloud is configured. If you didn't have volumes attached to the instance<br>>>> at all then this wouldn't matter.<br>>>><br>>>> I think in an earlier version of the patch it was reloading and checking<br>>>> the connection info every time the BDM list was retrieved for an<br>>>> instance, which was a major issue for normal operations where this isn't<br>>>> a problem.<br>>>><br>>>> Since it's been scoped to just start/reboot operations, it's better, and<br>>>> there are comments in the patch to make it a bit more efficient also<br>>>> (avoid calling the DB multiple times for the same information).<br>>>><br>>>> I'm not totally opposed to doing the refresh on start/reboot. We could<br>>>> make it configurable, so if you're using a storage server backend where<br>>>> the IP might change, then set this flag, but that's a bit clunky. And a<br>>>> periodic task wouldn't help us out.<br>>>><br>>>> I'm open to other ideas if anyone has them.<br>>><br>>><br>>> I was thinking it may be possible to do something similar to how network<br>>> info is periodically refreshed in _heal_instance_info_cache [1]. The<br>>> task interval is configurable (defaults to 60 seconds) and works on a<br>>> queue of instances such that one is refreshed per period, to control the<br>>> load on the host. To avoid doing anything for storage backends that<br>>> can't change IP, maybe we could make the task return immediately after<br>>> calling a driver method that would indicate whether the storage backend<br>>> can be affected by an IP change.<br>>><br>>> There would be some delay until the task runs on an affected instance,<br>>> though.<br>>><br>>> -melanie<br>>><br>>><br>>> [1]<br>>> <a href="https://github.com/openstack/nova/blob/9a05d38/nova/compute/manager.py#L5549">https://github.com/openstack/nova/blob/9a05d38/nova/compute/manager.py#L5549</a><br>>><br>>><br>>> __________________________________________________________________________<br>>> OpenStack Development Mailing List (not for usage questions)<br>>> Unsubscribe: OpenStack-dev-request at <a href="http://lists.openstack.org?subject:unsubscribe">lists.openstack.org?subject:unsubscribe</a><br>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>>><br>><br>>I like this idea. Sure it's a delay, but it resolves the problem <br>>eventually and doesn't add the overhead to the start/reboot operations <br>>that should mostly be unnecessary if things are working.<br>><br>>I like the short-circuit idea too, although that's a nice to have. A <br>>deployer can always disable the periodic task if they don't want that <br>>running.<br>><br>>-- <br>><br>>Thanks,<br>><br>>Matt Riedemann<br>><br><br></div>Hi Matt,<br><br></div>I was thinking, if it could be done on restarting of nova-compute service. <br></div>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.<br><br></div><div>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.<br><br></div><div>Please correct me if I am wrong.<br><br></div><div>Regards,<br></div><div>Rajesh<br></div></div>