Open Stack

On Feb 4, 2013, at 3:59 AM, Hans Lindgren <hanlind at kth.se> wrote:

> This is in regard to comments in the code review for blueprint utilization-based-scheduling found at https://review.openstack.org/#/c/18462/
>  
> This blueprint is currently blocked over naming of new filters added to the scheduler.
>  
> Some background:
> Current scheduling is done based on static allocation of resources, like the number of vCPUs or the amount of memory that has been granted to an instance. With this blueprint we introduce alternative criteria to base scheduling decisions on to allow for more effective use of resources. This is done by collecting actual resource consumption of the host (currently CPU+memory) and by complementing existing filters and weighers with new ones that acts upon the added stats.
>  
> The good thing with this approach is that the default behaviour of the scheduler doesn't change with the introduction of this blueprint. You must actively choose to enable this new scheduling policy by configuring filters and weighers to be used.
>  
> Now to the problem.
> Since we end up having dual filters acting on the same resource (ex. RamFilter/RamUsageFilter), we need to figure out the best way to name them to avoid confusion.
>  
> During review, it was proposed that existing filters (RamFilter and CoreFilter) should also be renamed to end up with *StaticFilter/*DynamicFilter or *PredictiveFilter/*UsageFilter. Later on an objection was made that this would break existing configs, forcing upgraders to change configs over such a change.
>  
> To be able to move on with the review I would like to hear your opinions on this matter. The filters affected, and their current names are:
> CoreFilter (existing filter)
> RAMFilter (existing filter)
> CPUUsageFilter
> RAMUsageFilter


There is no reason to break existing configs so I suggest keeping the names of the existing filters the same

Vish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130204/d44bfec7/attachment.html>