<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Don,<br>
      My additions inline.<br>
      <br>
      <br>
      Le 21/05/2014 00:38, Dugger, Donald D a écrit :<br>
    </div>
    <blockquote
cite="mid:6AF484C0160C61439DE06F17668F3BCB532CC681@ORSMSX114.amr.corp.intel.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1901748865;
        mso-list-type:hybrid;
        mso-list-template-ids:-1307143170 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-text:"%1\)";
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l0:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <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:<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoListParagraph"
          style="text-indent:-.25in;mso-list:l0 level1
          lfo1;text-autospace:none">
          <!--[if !supportLists]--><span
            style="font-family:"Courier New""><span
              style="mso-list:Ignore">1)<span style="font:7.0pt
                "Times New Roman""> 
              </span></span></span><!--[endif]--><span
            style="font-family:"Courier New"">Future of gantt
            interfaces & APIs (Sylvain Bauza)<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-family:"Courier New""><a
              moz-do-not-send="true"
              href="https://etherpad.openstack.org/p/juno-nova-gantt-apis">https://etherpad.openstack.org/p/juno-nova-gantt-apis</a><o:p></o:p></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.<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-family:"Courier New""><o:p> </o:p></span></p>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote
cite="mid:6AF484C0160C61439DE06F17668F3BCB532CC681@ORSMSX114.amr.corp.intel.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoListParagraph"
          style="text-indent:-.25in;mso-list:l0 level1
          lfo1;text-autospace:none">
          <!--[if !supportLists]--><span
            style="font-family:"Courier New""><span
              style="mso-list:Ignore">2)<span style="font:7.0pt
                "Times New Roman""> 
              </span></span></span><!--[endif]--><span
            style="font-family:"Courier New"">Common no DB
            scheduler (Boris)<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-family:"Courier New""><a
              moz-do-not-send="true"
              href="https://etherpad.openstack.org/p/juno-nova-no-db-scheduler">https://etherpad.openstack.org/p/juno-nova-no-db-scheduler</a><o:p></o:p></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.<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-family:"Courier New""><o:p> </o:p></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.<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-family:"Courier New""><o:p> </o:p></span></p>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote
cite="mid:6AF484C0160C61439DE06F17668F3BCB532CC681@ORSMSX114.amr.corp.intel.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoListParagraph"
          style="text-indent:-.25in;mso-list:l0 level1
          lfo1;text-autospace:none">
          <!--[if !supportLists]--><span
            style="font-family:"Courier New""><span
              style="mso-list:Ignore">3)<span style="font:7.0pt
                "Times New Roman""> 
              </span></span></span><!--[endif]--><span
            style="font-family:"Courier New"">Simultaneous
            scheduling for server groups (Mike Spreitzer)<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-family:"Courier New""><a
              moz-do-not-send="true"
href="https://etherpad.openstack.org/p/juno-nova-scheduling-server-groups">https://etherpad.openstack.org/p/juno-nova-scheduling-server-groups</a><o:p></o:p></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.<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-family:"Courier New""><o:p> </o:p></span></p>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:6AF484C0160C61439DE06F17668F3BCB532CC681@ORSMSX114.amr.corp.intel.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoListParagraph"
          style="text-indent:-.25in;mso-list:l0 level1
          lfo1;text-autospace:none">
          <!--[if !supportLists]--><span
            style="font-family:"Courier New""><span
              style="mso-list:Ignore">4)<span style="font:7.0pt
                "Times New Roman""> 
              </span></span></span><!--[endif]--><span
            style="font-family:"Courier New"">Scheduler hints
            for VM lifecycle (Jay Lau)<o:p></o:p></span></p>
        <p class="MsoNormal" style="text-autospace:none"><span
            style="font-family:"Courier New""><a
              moz-do-not-send="true"
href="https://etherpad.openstack.org/p/juno-nova-scheduler-hints-vm-lifecycle">https://etherpad.openstack.org/p/juno-nova-scheduler-hints-vm-lifecycle</a><o:p></o:p></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.<o:p></o:p></span></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
    </blockquote>
    <br>
    No clear consensus on that session IIRC.<br>
    <br>
    <br>
    -Sylvain<br>
    <blockquote
cite="mid:6AF484C0160C61439DE06F17668F3BCB532CC681@ORSMSX114.amr.corp.intel.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">--<o:p></o:p></p>
        <p class="MsoNormal">Don Dugger<o:p></o:p></p>
        <p class="MsoNormal">"Censeo Toto nos in Kansa esse decisse." -
          D. Gale<o:p></o:p></p>
        <p class="MsoNormal">Ph: 303/443-3786<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>