[openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling

Boris Pavlovic boris at pavlovic.ru
Fri Jul 19 15:49:46 UTC 2013


I think that current approach of Scheduler is not scalable and not flexible. if we add key/value this will make our scheduler flexible but with tons of hacks and less scalable.  We will get a tons of problems even on small 1k nodes cloud. 

We found another approach (just remove DB) this will solve all our problems. There is another thread with link to google doc, with large description. 

https://docs.google.com/document/d/1_DRv7it_mwalEZzLy5WO92TJcummpmWL4NWsWf0UWiQ/edit#

19.07.2013, в 19:30, Sean Dague <sean at dague.net> написал(а):

> On 07/19/2013 10:37 AM, Murray, Paul (HP Cloud Services) wrote:
>> If we agree that "something like capabilities" should go through Nova, what do you suggest should be done with the change that sparked this debate: https://review.openstack.org/#/c/35760/
>> 
>> I would be happy to use it or a modified version.
> 
> CPU sys, user, idle, iowait time isn't capabilities though. That's a dynamically changing value. I also think the current approach where this is point in time sampling, because we only keep a single value, is going to cause some oddly pathologic behavior if you try to use it as scheduling criteria.
> 
> I'd really appreciate the views of more nova core folks on this thread, as it looks like these blueprints have seen pretty minimal code review at this point. H3 isn't that far away, and there is a lot of high priority things ahead of this, and only so much coffee and review time in a day.
> 
>   -Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130719/4b249a63/attachment.html>


More information about the OpenStack-dev mailing list