I'm not sure it's a good moment for this but I would like to re-open the topic a little bit.
Just a small idea: is it OK if we use a file, or a database as a central point to store the policies and their associated aggregates? The Scheduler reads it first, then calls the scheduler drivers listed in the policy file for the associated aggregates. In this case we can get the list of filters and targeted aggregates before actually running the filters. Thus we avoid the loop filter -> aggregate -> policy -> filter ->. Moreover, admin does not need to populate the flavors' extra_specs or associate them with the aggregates, effectively avoiding defining two different policies in 2 flavors whose VMs are eventually hosted in a same aggregate. The downside of this method is that it is not API-accessible: at the current state we do not have a policy management system. I would like a policy management system with REST API, but still, it is not worse than using nova config. Best regards, Toan Alex Glikson GLIKSON at il.ibm.com Wed Aug 21 17:25:30 UTC 2013 Just to update those who are interested in this feature but were not able to follow the recent commits, we made good progress converging towards a simplified design, based on combination of aggregates and flavors (both of which are API-drvien), addressing some of the concerns expressed in this thread (at least to certain extent). The current design and possible usage scenario has been updated at https://wiki.openstack.org/wiki/Nova/MultipleSchedulerPolicies Comments are welcome (as well as code reviews at https://review.openstack.org/#/c/37407/). Thanks, Alex From: Joe Gordon <joe.gordon0 at gmail.com> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>, Date: 27/07/2013 01:22 AM Subject: Re: [openstack-dev] [Nova] support for multiple active scheduler policies/drivers On Wed, Jul 24, 2013 at 6:18 PM, Alex Glikson <GLIKSON at il.ibm.com> wrote: Russell Bryant <rbryant at redhat.com> wrote on 24/07/2013 07:14:27 PM: > > I really like your point about not needing to set things up via a config > file. That's fairly limiting since you can't change it on the fly via > the API. True. As I pointed out in another response, the ultimate goal would be to have policies as 'first class citizens' in Nova, including a DB table, API, etc. Maybe even a separate policy service? But in the meantime, it seems that the approach with config file is a reasonable compromise in terms of usability, consistency and simplicity. I do like your idea of making policies first class citizens in Nova, but I am not sure doing this in nova is enough. Wouldn't we need similar things in Cinder and Neutron? Unfortunately this does tie into how to do good scheduling across multiple services, which is another rabbit hole all together. I don't like the idea of putting more logic in the config file, as it is the config files are already too complex, making running any OpenStack deployment require some config file templating and some metadata magic (like heat). I would prefer to keep things like this in aggregates, or something else with a REST API. So why not build a tool on top of aggregates to push the appropriate metadata into the aggregates. This will give you a central point to manage policies, that can easily be updated on the fly (unlike config files). In the long run I am interested in seeing OpenStack itself have a strong solution for for policies as a first class citizen, but I am not sure if your proposal is the best first step to do that. Regards, Alex > -- > Russell Bryant _______________________________________________ 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 _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev