[openstack-dev] [nova] blueprint about multiple workers supported in nova-scheduler

Attila Fazekas afazekas at redhat.com
Wed Mar 4 09:51:21 UTC 2015


I wonder what is the planned future of the scheduling.

The scheduler does a lot of high field number query,
which is CPU expensive when you are using sqlalchemy-orm.
Does anyone tried to switch those operations to sqlalchemy-core ?

The scheduler does lot of thing in the application, like filtering 
what can be done on the DB level more efficiently. Why it is not done
on the DB side ? 

There are use cases when the scheduler would need to know even more data,
Is there a plan for keeping `everything` in all schedulers process memory up-to-date ?
(Maybe zookeeper)

The opposite way would be to move most operation into the DB side,
since the DB already knows everything. 
(stored procedures ?)

Best Regards,

----- Original Message -----
> From: "Rui Chen" <chenrui.momo at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Wednesday, March 4, 2015 4:51:07 AM
> Subject: [openstack-dev] [nova] blueprint about multiple workers supported	in nova-scheduler
> Hi all,
> I want to make it easy to launch a bunch of scheduler processes on a host,
> multiple scheduler workers will make use of multiple processors of host and
> enhance the performance of nova-scheduler.
> I had registered a blueprint and commit a patch to implement it.
> https://blueprints.launchpad.net/nova/+spec/scheduler-multiple-workers-support
> This patch had applied in our performance environment and pass some test
> cases, like: concurrent booting multiple instances, currently we didn't find
> inconsistent issue.
> IMO, nova-scheduler should been scaled horizontally on easily way, the
> multiple workers should been supported as an out of box feature.
> Please feel free to discuss this feature, thanks.
> Best Regards
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list