2014-05-21 15:50 GMT+08:00 Sylvain Bauza <sba...@redhat.com>: > Hi Don, > My additions inline. > > > Le 21/05/2014 00:38, Dugger, Donald D a écrit : > > 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. > > > > > As the devil is in the details, most of this work is quite straightforward > but needs to address a lot of details. One example of this is how we deal > with aggregates for filtering upon them : how the scheduler has to access > aggregates info, that is purely Nova ? > As we can't address all the concerns directly in the blueprints, I think > the best way to find out all the problems is to do a weekly update of the > progress in these important blueprints for Gantt, and raise during these > meetings all the implementation problems we could face. > > > 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. > > > > > I just want to mention here that the idea was widely accepted, only the > details about how it will be implemented were debated hugely. I can propose > to further discuss these implementation details during a next meeting, as > Yuriy Taraday who is the identified contributor to these BPs was unable to > attend the Summit. > > > > 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. > > > > > The formal conclusion was to discuss with Climate team (whose I'm part of > as Climate core reviewer) in order to see how Climate can provide the > reservation by itself. Nova team agreed that probably Climate could need to > request Nova for doing the simultaneous scheduling, but in that case it's > up to Climate responsibility to raise the topic and ask Nova to do anything > related to it. > Heat was discussed as possible top-level system for asking the reservation > ie. requesting reservation to Climate, IIRC. > > > > > 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 J No clear consensus on what to do, more research > needed. > > > > > > > No clear consensus on that session IIRC. > I have just updated the patch here: https://review.openstack.org/#/c/88983/, I'm planning to add a new field to instance table for the solution.
> > > -Sylvain > > > > -- > > Don Dugger > > "Censeo Toto nos in Kansa esse decisse." - D. Gale > > Ph: 303/443-3786 > > > > > _______________________________________________ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Thanks, Jay
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev