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.gord...@gmail.com> To: OpenStack Development Mailing List <openstack-dev@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 <glik...@il.ibm.com> wrote: Russell Bryant <rbry...@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@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
