On Mon, Jul 22, 2013 at 3:04 PM, Russell Bryant <rbry...@redhat.com> wrote:
> On 07/22/2013 05:15 PM, Alex Glikson wrote: > > Dear all, > > > > Following the initial discussions at the last design summit, we have > > published the design [2] and the first take on the implementation [3] of > > the blueprint adding support for multiple active scheduler > > policies/drivers [1]. > > In a nutshell, the idea is to allow overriding the 'default' scheduler > > configuration parameters (driver, filters, their configuration > > parameters, etc) for particular host aggregates. The 'policies' are > > introduced as sections in nova.conf, and each host aggregate can have a > > key-value specifying the policy (by name). > > > > Comments on design or implementation are welcome! > > > > Thanks, > > Alex > > > > > > [1] > https://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers > > [2] https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies > > [3] https://review.openstack.org/#/c/37407/ > > Thanks for bringing this up. I do have some comments. > > The current design shows 2 different use cases for how a scheduling > policy would be chosen. > > #1 - policy associated with a host aggregate > > This seems very odd to me. Scheduling policy is what chooses hosts, so > having a subset of hosts specify which policy to use seems backwards. > > #2 - via a scheduler hint > > It also seems odd to have the user specifying scheduling policy. This > seems like something that should be completely hidden from the user. > > How about just making the scheduling policy choice as simple as an item > in the flavor extra specs? > ++, IMHO we already reveal too much scheduling information to the user via are current set of scheduler hints. > > The design also shows some example configuration. It shows a global set > of enabled scheduler filters, and then policy specific tweaks of filter > config (CPU allocation ratio in the example). I would expect to be able > to set a scheduling policy specific list of scheduler filters and > weights, as well. > > -- > Russell Bryant > > _______________________________________________ > 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
