Cache calls to "qemu-img info"

[Michael Still]

We keep calling this command over and over to find out how over committed disk is. However, the output that we care about (total size of the image, not total size on disk) is very unlikely to change. We could instead have a cache and then invalidate cache entries if we resized an image.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/25809

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/25959

[Russell Bryant (russellb)]

This seems to have been abandoned a while ago. Planning to pick it back up?

[Nikola Đipanov (ndipanov)]

There seems to be another issue with this that will still result in an unneeded qemu-img info call:

libvirt driver's get_instance_disk_info calls qemu-img info twice:

if disk_type == "qcow2":
                backing_file = libvirt_utils.get_disk_backing_file(path) <--- one call
                virt_size = disk.get_disk_size(path) <---- second call
                over_commit_size = int(virt_size) - dk_size

We can cache the size and also avoid the second call entirely by simply refactoring these two utility functions.

[Thang Pham (thang-pham)]

Based on the patch that Michael Still proposed last year, is memcache still the appropriate solution to caching "qemu-img info" calls? Or is everyone opposed to it?

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY