> From: Joe Gordon [mailto:joe.gord...@gmail.com] > Sent: 26 July 2013 23:16 > To: OpenStack Development Mailing List > 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 think we need to be looking in the future to being able to delegate large parts of the functionality that is currently "admin only" in Nova, and a large part of that is moving things like this from the config file into APIs. Once we have the Domain capability in ketystone fully available to services like Nova we need to think more about ownership of resources like hosts, and being able to delegate this kind of capability. >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). I agree with Jo on this point, and his is the approach we're taking with the Pcloud / whole-host-allocation blueprint: https://review.openstack.org/#/c/38156/ https://wiki.openstack.org/wiki/WholeHostAllocation I don't think realistically we'll be able to land this in Havana now (as much as anything I don't think it had enough air time yet to be sure we have a consensus on all of the details) but Rackspace are now helping with part of this and we do expect to have something in a PoC / Demonstratable state for the Design Summit to provide a more focused discussion. Because the code is layered on top of existing aggregate and scheduler features its pretty easy to keep it as something we can just keep rebasing. Regards, Phil _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
