<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-21 15:50 GMT+08:00 Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Don,<br>
My additions inline.<br>
<br>
<br>
Le 21/05/2014 00:38, Dugger, Donald D a écrit :<br>
</div><div class="">
<blockquote type="cite">
<div>
<p class="MsoNormal">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:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p style="text-autospace:none">
<span style="font-family:"Courier New""><span>1)<span style="font:7pt "Times New Roman"">
</span></span></span><span style="font-family:"Courier New"">Future of gantt
interfaces & APIs (Sylvain Bauza)<u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New""><a href="https://etherpad.openstack.org/p/juno-nova-gantt-apis" target="_blank">https://etherpad.openstack.org/p/juno-nova-gantt-apis</a><u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New"">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.<u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New""><u></u> <u></u></span></p>
</div>
</blockquote>
<br></div>
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 ?<br>
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.<div class=""><br>
<br>
<blockquote type="cite">
<div>
<p style="text-autospace:none">
<span style="font-family:"Courier New""><span>2)<span style="font:7pt "Times New Roman"">
</span></span></span><span style="font-family:"Courier New"">Common no DB
scheduler (Boris)<u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New""><a href="https://etherpad.openstack.org/p/juno-nova-no-db-scheduler" target="_blank">https://etherpad.openstack.org/p/juno-nova-no-db-scheduler</a><u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New"">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.<u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New""><u></u> <u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New"">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.<u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New""><u></u> <u></u></span></p>
</div>
</blockquote>
<br></div>
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.<div class=""><br>
<br>
<br>
<blockquote type="cite">
<div>
<p style="text-autospace:none">
<span style="font-family:"Courier New""><span>3)<span style="font:7pt "Times New Roman"">
</span></span></span><span style="font-family:"Courier New"">Simultaneous
scheduling for server groups (Mike Spreitzer)<u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New""><a href="https://etherpad.openstack.org/p/juno-nova-scheduling-server-groups" target="_blank">https://etherpad.openstack.org/p/juno-nova-scheduling-server-groups</a><u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New"">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.<u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New""><u></u> <u></u></span></p>
</div>
</blockquote>
<br></div>
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.<br>
Heat was discussed as possible top-level system for asking the
reservation ie. requesting reservation to Climate, IIRC.<div class=""><br>
<br>
<br>
<br>
<blockquote type="cite">
<div>
<p style="text-autospace:none">
<span style="font-family:"Courier New""><span>4)<span style="font:7pt "Times New Roman"">
</span></span></span><span style="font-family:"Courier New"">Scheduler hints
for VM lifecycle (Jay Lau)<u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New""><a href="https://etherpad.openstack.org/p/juno-nova-scheduler-hints-vm-lifecycle" target="_blank">https://etherpad.openstack.org/p/juno-nova-scheduler-hints-vm-lifecycle</a><u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-family:"Courier New"">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 </span><span style="font-family:Wingdings">J</span><span style="font-family:"Courier New""> No clear
consensus on what to do, more research needed.<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</blockquote>
<br></div>
No clear consensus on that session IIRC.<br></div></blockquote><div>I have just updated the patch here: <a href="https://review.openstack.org/#/c/88983/">https://review.openstack.org/#/c/88983/</a> , I'm planning to add a new field to instance table for the solution. <br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
<br>
-Sylvain<br>
<blockquote type="cite"><div class="">
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">--<u></u><u></u></p>
<p class="MsoNormal">Don Dugger<u></u><u></u></p>
<p class="MsoNormal">"Censeo Toto nos in Kansa esse decisse." -
D. Gale<u></u><u></u></p>
<p class="MsoNormal">Ph: <a href="tel:303%2F443-3786" value="+13034433786" target="_blank">303/443-3786</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<br>
<fieldset></fieldset>
<br>
</div><pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Thanks,<br><br></div>Jay<br></div>
</div></div>