<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi Nova developers,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is about the patch: <a href="https://review.openstack.org/#/c/200870/19">
https://review.openstack.org/#/c/200870/19</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We would like to fix this issue in Newton and back port it to Mitaka.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Reason: <o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This issue is discussed in Thu Aug 11 14:00:18 2016 UTC Nova meeting [1] and community came to conclusion that:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We need to fix this issue in Newton but<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Not willing to modify instance root_gb that is stored in instances db table.<o:p></o:p></p>
<p class="MsoNormal">2. Suggested to fix this issue in RT but that won't solve the scheduler DiskFilter issue completely.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We have following approach in mind:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Scheduler DiskFilter should ignore root_gb from RequestSpec if instance is booted from volume.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Resource tracker should also ignore root_gb while updating compute disk metrics.<o:p></o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So the entire logic is based on image_ref of instance, it should be None if instance is booted from volume.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Please let me know your opinion about the same or you have any other solution in mind.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">[1] <a href="http://eavesdrop.openstack.org/meetings/nova/2016/nova.2016-08-11-14.00.log.html">
http://eavesdrop.openstack.org/meetings/nova/2016/nova.2016-08-11-14.00.log.html</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thank you,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Abhishek Kekane<o:p></o:p></p>
</div>
<br clear="both">
______________________________________________________________________<BR>
Disclaimer: This email and any attachments are sent in strictest confidence<BR>
for the sole use of the addressee and may contain legally privileged,<BR>
confidential, and proprietary data. If you are not the intended recipient,<BR>
please advise the sender by replying promptly to this email and then delete<BR>
and destroy this email and any attachments without any further use, copying<BR>
or forwarding.<BR>
</body>
</html>