+1, makes sense to me.
On Wed, Jun 4, 2014 at 3:08 PM, Yingjun Li <liyingjun1...@gmail.com> wrote: > +1, if doing so, a related bug related bug may be solved as well: > https://bugs.launchpad.net/nova/+bug/1323538 > > On Jun 3, 2014, at 21:29, Jay Pipes <jaypi...@gmail.com> wrote: > > Hi Stackers, > > tl;dr > ===== > > Move CPU and RAM allocation ratio definition out of the Nova scheduler and > into the resource tracker. Remove the calculations for overcommit out of > the core_filter and ram_filter scheduler pieces. > > Details > ======= > > Currently, in the Nova code base, the thing that controls whether or not > the scheduler places an instance on a compute host that is already "full" > (in terms of memory or vCPU usage) is a pair of configuration options* > called cpu_allocation_ratio and ram_allocation_ratio. > > These configuration options are defined in, respectively, > nova/scheduler/filters/core_filter.py and > nova/scheduler/filters/ram_filter.py. > > Every time an instance is launched, the scheduler loops through a > collection of host state structures that contain resource consumption > figures for each compute node. For each compute host, the core_filter and > ram_filter's host_passes() method is called. In the host_passes() method, > the host's reported total amount of CPU or RAM is multiplied by this > configuration option, and the product is then subtracted from the reported > used amount of CPU or RAM. If the result is greater than or equal to the > number of vCPUs needed by the instance being launched, True is returned and > the host continues to be considered during scheduling decisions. > > I propose we move the definition of the allocation ratios out of the > scheduler entirely, as well as the calculation of the total amount of > resources each compute node contains. The resource tracker is the most > appropriate place to define these configuration options, as the resource > tracker is what is responsible for keeping track of total and used resource > amounts for all compute nodes. > > Benefits: > > * Allocation ratios determine the amount of resources that a compute node > advertises. The resource tracker is what determines the amount of resources > that each compute node has, and how much of a particular type of resource > have been used on a compute node. It therefore makes sense to put > calculations and definition of allocation ratios where they naturally > belong. > * The scheduler currently needlessly re-calculates total resource amounts > on every call to the scheduler. This isn't necessary. The total resource > amounts don't change unless either a configuration option is changed on a > compute node (or host aggregate), and this calculation can be done more > efficiently once in the resource tracker. > * Move more logic out of the scheduler > * With the move to an extensible resource tracker, we can more easily > evolve to defining all resource-related options in the same place (instead > of in different filter files in the scheduler...) > > Thoughts? > > Best, > -jay > > * Host aggregates may also have a separate allocation ratio that overrides > any configuration setting that a particular host may have > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Best Regards, Zhenguo Niu
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
