On 5/16/2016 8:39 PM, zhou.b...@zte.com.cn wrote:
Hi all：I got a problem described in https://bugs.launchpad.net/cinder/+bug/1452641, and my colleague got another similar problem described in https://bugs.launchpad.net/nova/+bug/1581367. It's all about the storage backend ip change. With the storage backend, not only Ceph but also IPSAN, when the backend's ip changed, the related volumes attached to VMs would not be available. Previously I proposed to auto-check the consistency of IP record in nova's bdm table and storage backend, which was submitted in https://review.openstack.org/#/c/289813/. reviewers point out that it's a waste of performance with normal case and it's a not a good scenario to do thess checking in a regular function. I agree with this suggestion and the bug troubled me and my colleagues all the time. I think if we can just add an option in nova api, such as "nova reboot --refresh-conn" to manually modify the VM's bdm info when the bug happened. The "--refresh-conn" was parsed and passed to "reboot_instance" function in nova-compute. Without auto-checking, it would be more flexible and efficient. And I need all of your valued opinions and appreciate for hearing from you soon. The fake code is like this in nova-compute: def reboot_instance(self, context, instance, block_device_info, reboot_type, refresh_conn = False): """Reboot an instance on this host.""" ... ... block_device_info = self._get_instance_block_device_info(context, instance, refresh_conn) Thank you. related links are as follows: https://bugs.launchpad.net/cinder/+bug/1452641 https://bugs.launchpad.net/nova/+bug/1581367 https://review.openstack.org/#/c/289813/ -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. __________________________________________________________________________ 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
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. -- 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
