>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] >> 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 >running. > >-- > >Thanks, > >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. Regards, Rajesh
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
