Here is a brief rundown on the majority of the scheduler sessions from the summit, links to the etherpads and some of my incoherent notes from the sessions. Feel free to reply to this email to correct any mistakes I made and to add any other thoughts you might have:
1) Future of gantt interfaces & APIs (Sylvain Bauza) https://etherpad.openstack.org/p/juno-nova-gantt-apis As from the last summit everyone agrees that yes a separate scheduler project is desirable but we need to clean up the interfaces between Nova and the scheduler first. There are 3 main areas that need to be cleaned up first (proxying for booting instances, a library to isolate the scheduler and isolate access to DB objects). We have BPs created for all of these areas so we need to implement those BPs first, all of that work happening in the current Nova tree. After those 3 steps are done we need to check for any other external dependencies (hopefully there aren't any) and then we can split the code out into the gantt repository. 2) Common no DB scheduler (Boris) https://etherpad.openstack.org/p/juno-nova-no-db-scheduler Pretty much agreement that the new no-db scheduler needs to be switchable/configurable so that it can be selected at run time, don't want to do a flash cut that requires everyone to suddenly switch to the new architecture, it should be possible to design this such that the node state info, currently kept in the DB, can be handled by a back end that can either use the current DB methods or the new no-db methods. Much discussion over the fact that the current patches use the memcached to contain a journal of all update messages about node state change which means that the scheduler will just be re-inventing journaling problems/solutions that are well handled by current DBs. Another idea would be to use the memcached area to hold complete state info for each node, using a counter mechanism to know when the data is out of date. Need to evaluate the pros/cons of different memcached designs. 3) Simultaneous scheduling for server groups (Mike Spreitzer) https://etherpad.openstack.org/p/juno-nova-scheduling-server-groups The basic idea is a desire to schedule a group of hosts in one call (more consistent with server groups) rather than multiple scheduler calls for one node at a time. Talking about this the real issue seem to be a resource reservation problem, the user wants to reserve a set of nodes and then, given the reservation succeeds, do the actual scheduling task. As such, this sounds like something that maybe should be integrated in with the climate and/or heat. Need to do some more research to see if this problem can be addressed and/or helped by either of those projects. 4) Scheduler hints for VM lifecycle (Jay Lau) https://etherpad.openstack.org/p/juno-nova-scheduler-hints-vm-lifecycle Basic problem is that server hints are only instance instantiation time, the info is then lost and not available for migration decisions, need to store the hints somehow. We could create a new table to hold the hints, we could add a new (arbitrary blob) field to the instances table or we could store the info in the system metadata which means we might need to resizulate the thingotron (that was the actual comment, interpretation is left to the reader :) No clear consensus on what to do, more research needed. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
