Open Stack

+1, makes sense to me.


On Wed, Jun 4, 2014 at 3:08 PM, Yingjun Li <liyingjun1988 at 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 <jaypipes at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best Regards,
Zhenguo Niu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140604/ecd645e1/attachment.html>