[openstack-dev] [nova] upgrade connection_info when Ceph mon IP changed
mriedem at linux.vnet.ibm.com
Wed May 18 19:30:00 UTC 2016
On 5/16/2016 8:39 PM, zhou.bin9 at zte.com.cn wrote:
> Hi all：
> I got a problem described in
> and my colleague got another similar problem described in
> 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,
> Thank you.
> related links are as follows:
> -------------------------------------------------------- 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-request at lists.openstack.org?subject:unsubscribe
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
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.
More information about the OpenStack-dev