Hi Abhishek
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.
Thanks,
Feodor Tersin
From: Kekane, Abhishek <abhishek.kek...@nttdata.com>
Sent: Friday, August 12, 2016 4:29:11 PM
To: OpenStack Development Mailing List (openstack-dev@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.
Reason:
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 [1] 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.
[1]
http://eavesdrop.openstack.org/meetings/nova/2016/nova.2016-08-11-14.00.log.html
Thank you,
Abhishek Kekane
__
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
or forwarding.
__
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
