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-requ...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
