Hi, stackers, When reading code related to the resource tracker, I noticed AggregateRamFilter as in https://review.openstack.org/#/c/33828/.
I'm not sure if it's better to use per node configuration of ram ration, instead of depends on the host aggregate? Currently we have to have DB call for each scheduler call and is really a performance issue. Also, if any instance is scheduled to a host before the host aggregate is created/setup, a wrong ram ratio can cause trouble to host like OOM. With per node configuration, I'd add an column in DB to indicate memory_mb_limit, and this information will be provided by resource tracker. The benefits of the change are: a) The host have better idea of the memory limit usable. And we can even provide other method to calculate in resource tracker other than ration. b) it makes the flow more clean. Currently the resource tracker make claims decision with 'limits' passing from scheduler, that's a bit strange IMHO. I'd think scheduler makes the scheduler decision, instead of the resource calculation, while resource tracker provide resource information. I think the shortcoming of the per node configuration is, not so easy to change. But such information should mostly related to host configuration like swap size etc and should be more static and deployment setup should be ok. Any idea? Thanks --jyh _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
