Open Stack

2014-05-21 15:50 GMT+08:00 Sylvain Bauza <sbauza at 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 at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140521/91193c24/attachment.html>