Open Stack

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 
running.

-- 

Thanks,

Matt Riedemann