Open Stack

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