<font face="'Helvetica Neue', 'Helvetica Neue', Helvetica, Arial, sans-serif"><span style=" font-size:14px; font-family:'Helvetica Neue', 'Helvetica Neue', Helvetica, Arial, sans-serif;">+1 for this proposal. <div><br></div><div>We are highly interested in this one. <br><br><br><font color="#000000" face="Lucida Grande" style="font-size: 12px;">Jaesuk Ahn, Ph.D.  </font><div><span style="font-size: 12px; color: rgb(0, 0, 0); font-family: 'Lucida Grande#!&*@&; line-height: 1.428571429;">Team Lead, Next Generation Cloud Platform Dev. Project </span></div><div><div><font color="#000000" face="Lucida Grande" style="font-size: 12px;">KT </font></div></div><div><font color="#000000" face="Lucida Grande" style="font-size: 12px;"><i><br></i></font></div><div><font color="#000000" face="Lucida Grande"><i><span style="font-size: 12px; line-height: 17px;">…</span><span style="font-size: 12px;"> active member of openstack community</span></i></font></div><div id="replyBeginsHere"><br><br><br>On Jun 4, 2014, 5:29:36 PM, John Garbutt <john@johngarbutt.com> wrote:<hr><div class="linkMe">On 3 June 2014 14:29, Jay Pipes </div><br><br><div class="linkMe"><<a href="mailto:jaypipes@gmail.com" target="_blank">mailto:jaypipes@gmail.com</a>> wrote:<br>> tl;dr<br>> =====<br>> <br>> Move CPU and RAM allocation ratio definition out of the Nova scheduler and<br>> into the resource tracker. Remove the calculations for overcommit out of the<br>> core_filter and ram_filter scheduler pieces.<br><br>+1<br><br>I hope to see us send more specific stats to the scheduler, that each<br>filter/weigher can then interpret.<br><br>The extensible system then means you can optimise what you send down<br>the scheduler to a minimum. The next step is doing differential<br>updates, with more infrequent full sync updates. But we are getting<br>there.<br><br>As you say, I love that we do the calculation once per host, not once<br>per request. It plays really well with the caching scheduler work, and<br>the new build and run instance flow that help work towards the<br>scheduler process(es) doing the bare minimum on each user request.<br><br>> Details<br>> =======<br>> <br>> Currently, in the Nova code base, the thing that controls whether or not the<br>> scheduler places an instance on a compute host that is already "full" (in<br>> terms of memory or vCPU usage) is a pair of configuration options* called<br>> cpu_allocation_ratio and ram_allocation_ratio.<br>> <br>> These configuration options are defined in, respectively,<br>> nova/scheduler/filters/core_filter.py and<br>> nova/scheduler/filters/ram_filter.py.<br>> <br>> Every time an instance is launched, the scheduler loops through a collection<br>> of host state structures that contain resource consumption figures for each<br>> compute node. For each compute host, the core_filter and ram_filter's<br>> host_passes() method is called. In the host_passes() method, the host's<br>> reported total amount of CPU or RAM is multiplied by this configuration<br>> option, and the product is then subtracted from the reported used amount of<br>> CPU or RAM. If the result is greater than or equal to the number of vCPUs<br>> needed by the instance being launched, True is returned and the host<br>> continues to be considered during scheduling decisions.<br>> <br>> I propose we move the definition of the allocation ratios out of the<br>> scheduler entirely, as well as the calculation of the total amount of<br>> resources each compute node contains. The resource tracker is the most<br>> appropriate place to define these configuration options, as the resource<br>> tracker is what is responsible for keeping track of total and used resource<br>> amounts for all compute nodes.<br><br>+1<br><br>> Benefits:<br>> <br>> * Allocation ratios determine the amount of resources that a compute node<br>> advertises. The resource tracker is what determines the amount of resources<br>> that each compute node has, and how much of a particular type of resource<br>> have been used on a compute node. It therefore makes sense to put<br>> calculations and definition of allocation ratios where they naturally<br>> belong.<br>> * The scheduler currently needlessly re-calculates total resource amounts<br>> on every call to the scheduler. This isn't necessary. The total resource<br>> amounts don't change unless either a configuration option is changed on a<br>> compute node (or host aggregate), and this calculation can be done more<br>> efficiently once in the resource tracker.<br>> * Move more logic out of the scheduler<br>> * With the move to an extensible resource tracker, we can more easily<br>> evolve to defining all resource-related options in the same place (instead<br>> of in different filter files in the scheduler...)<br><br>+1<br><br>Thats a much nicer solution than shoving info from the aggregate into<br>the scheduler. Great to avoid that were possible.<br><br><br>Now there are limits to this, I think. Some examples that to mind:<br>* For per aggregate ratios, we just report the free resources, taking<br>into account the ratio. (as above)<br>* For the availability zone filter, each host should report its<br>availability zone to the scheduler<br>* If we have filters that adjust the ratio per flavour, we will still<br>need that calculation in the scheduler, but thats cool<br><br><br>In general, the approach I am advocating is:<br>* each host provides the data needed for the filter / weightier<br>* ideally in a way that requires minimal processing<br><br>And after some IRC discussions with Dan Smith, he pointed out that we<br>need to think about:<br>* with data versioned in a way that supports live-upgrades<br><br><br>Thanks,<br>John<br><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">mailto:OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a> </div><br><br></div></div></span></font>