Open Stack

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.


-Sylvain
>
>  
>
> --
>
> Don Dugger
>
> "Censeo Toto nos in Kansa esse decisse." - D. Gale
>
> Ph: 303/443-3786
>
>  
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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