[openstack-dev] [nova] Fix evaluation of host disk usage by volume-backed instances
ftersin at hotmail.com
Fri Aug 12 13:58:38 UTC 2016
There were a number of tries to analyze if an instance is booted from volume in DiskFilter itself. All reviews were stopped by core team members.
As for you assume about image_ref is None for such instances, it is not right for an instance booted from a volume backed image (a snapshot of another volume backed instance). In this case image_ref refers to the snapshot - Glance image which does not contain data, but which metadata has links to volume snapshot(s).
You also need to keep in mind that many other parts of code uses root_gb directly. E.g. nova-manage script calculates size of used host space by it (at least it did that a year ago).
Another thing (why i stopped to work on it) is that this change (setting root_gb to 0) does not fix resize case. In this case scheduler and other components must not check root_gb, but must do checks with corresponded attribute of a new flavor. And i did not found an easy way how to provide there the fact that root_gb need to be ignored.
I hope these info was useful for you.
From: Kekane, Abhishek <Abhishek.Kekane at nttdata.com>
Sent: Friday, August 12, 2016 4:29:11 PM
To: OpenStack Development Mailing List (openstack-dev at lists.openstack.org)
Subject: [openstack-dev] [nova] Fix evaluation of host disk usage by volume-backed instances
Hi Nova developers,
This is about the patch: https://review.openstack.org/#/c/200870/19
We would like to fix this issue in Newton and back port it to Mitaka.
Ubuntu 16.04 LTS supports Mitaka release. If we wait for this fix until Ocata release (~April 2017), then Ubuntu team might need some more time to release Ocata in 16.04 (~Oct 2017). I think it will be too late to fix such an important and critical issue. Now on the other hand, if we fix this issue in Newton and back port it to Mitaka, the chances of getting this fix in Ubuntu 16.04 increases and it would be available to the Ubuntu users anytime between Oct and Dec of this year.
We admit that this patch is a hack but considering its severity, it’s important to get it fixed as early as possible. Moreover, this code has been reviewed by many eyes so far and I don’t see its breaking current functionality. After this issue is fixed in the Ocata release during resource-providers implementation, we can delete these changes.
This issue is discussed in Thu Aug 11 14:00:18 2016 UTC Nova meeting  and community came to conclusion that:
We need to fix this issue in Newton but
1. Not willing to modify instance root_gb that is stored in instances db table.
2. Suggested to fix this issue in RT but that won't solve the scheduler DiskFilter issue completely.
We have following approach in mind:
1. Scheduler DiskFilter should ignore root_gb from RequestSpec if instance is booted from volume.
IMO boot server doesn't accept both image_id and volume_id to launch a new server. That means, if the instance is booted from volume, image_ref will always be None in the instances db table. i.e. instance.image_ref should be None. So, in the RequestSpec class, we should add an attribute "is_volume_backed' and set it to True when image is None. The Diskfilter has access to spec_obj, so simply check if is_volume_backed is True, if yes, ignore root_gb else count root_gb and take further action. This will solve the scheduler DiskFilter issue.
2. Resource tracker should also ignore root_gb while updating compute disk metrics.
Again in "_get_usage_dict" method of resource_tracker.py, check if image is None, if yes, simply set root_gb to 0. This way each compute node will report disk metrics to the scheduler correctly.
So the entire logic is based on image_ref of instance, it should be None if instance is booted from volume.
I am working on a POC with this approach and will test all possible scenarios (boot, resize, reboot, compute service stop/start, shelved-unshelved etc).
Please let me know your opinion about the same or you have any other solution in mind.
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev