Open Stack

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