<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Don,<br>
<br>
Adding [nova] in the subject too, because we could miss some people
here.<br>
<br>
<br>
<div class="moz-cite-prefix">Le 08/09/2014 07:24, Dugger, Donald D a
écrit :<br>
</div>
<blockquote
cite="mid:6AF484C0160C61439DE06F17668F3BCB53398D79@ORSMSX114.amr.corp.intel.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@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:716246898;
mso-list-type:hybrid;
mso-list-template-ids:-1244245630 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">As I mentioned in a prior email I think
that, although we’re in agreement on what needs to be done
before splitting out the scheduler into the Gantt project, I
believe we have different views on what that agreement
actually is. Given that we have multiple people that actively
want to work on this split I would like to try and put down
the specifics of what needs to be accomplished.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As I see it the top level issue is cleaning
up the internal interfaces between the Nova core code and the
scheduler, specifically:<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"><!--[if !supportLists]--><span
style="mso-list:Ignore">1)<span style="font:7.0pt
"Times New Roman"">
</span></span><!--[endif]-->The client interface<o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2
lfo1">
<!--[if !supportLists]--><span style="mso-list:Ignore">a.<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->Done – we’ve created and pushed
a patch to address this interface</p>
</div>
</blockquote>
+1. Scheduler-lib is now merged, but using JSON dicts to pass
updates to the scheduler.<br>
The main point of this blueprint is to create a new interface for
updating stats to the Scheduler, as RT was previously directly
sending DB modifications to the conductor (even not yet using
objects)<br>
<br>
<br>
<blockquote
cite="mid:6AF484C0160C61439DE06F17668F3BCB53398D79@ORSMSX114.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoListParagraph"
style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2
lfo1"><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="mso-list:Ignore">2)<span style="font:7.0pt
"Times New Roman"">
</span></span><!--[endif]-->Data-base access<o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2
lfo1">
<!--[if !supportLists]--><span style="mso-list:Ignore">a.<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->Ongoing – we’ve created a patch
that missed the Juno deadline, try again in Kilo</p>
</div>
</blockquote>
<br>
This isolate-scheduler-db blueprint was based on Extensible Resource
Tracker (ERT). As ERT is not yet fully merged upstream (the
scheduler part is still on review) and as it's not providing a clear
interface for stats (just adding nested dicts to a big JSON string),
we decided to review other opportunities for sending these updates
necessary for having the filters looking at HostState instead of
directly calling other Nova objects.<br>
<br>
<br>
<blockquote
cite="mid:6AF484C0160C61439DE06F17668F3BCB53398D79@ORSMSX114.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoListParagraph"
style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2
lfo1"><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="mso-list:Ignore">3)<span style="font:7.0pt
"Times New Roman"">
</span></span><!--[endif]-->Resource Tracker<o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2
lfo1">
<!--[if !supportLists]--><span style="mso-list:Ignore">a.<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->Identify what data is sent from
compute to scheduler<o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2
lfo1">
<!--[if !supportLists]--><span style="mso-list:Ignore">b.<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->Track that data inside the
scheduler<o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level2
lfo1">
<!--[if !supportLists]--><span style="mso-list:Ignore">c.<span
style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->Not started yet (being
discussed)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
To be precise, we need to clearly define the interface that the
Scheduler is exposing. As I said above, there is now another method
called update_resource_stats(name, stats) which provided a first
endpoint for sending updates to the Scheduler, but we need to
strengthen this method by having validation and typing here instead
of a blob.<br>
<br>
On the other hand, we also need to make sure that the claiming
mechanism is robust enough for supporting various kinds of claiming
(the NUMA patches that were sent proved that there is room for
improvement here). Ideally, the claiming system should be done on
the Scheduler itself (by having a distributed transactional model
for concurrent scheduling requests to multiple schedulers).<br>
<br>
<br>
<blockquote
cite="mid:6AF484C0160C61439DE06F17668F3BCB53398D79@ORSMSX114.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal">These to me are the critical items for the
split. Yes there are lots of other areas/interfaces inside
Nova that should be cleaned up but the goal here is to split
out the scheduler, not to refactor every interface inside
Nova.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
Indeed, we need to keep in track the objective to split the
Scheduler as soon as possible. That's why I'm proposing a strategy
of updating stats to the Scheduler by passing Nova objects
(ComputeNode here) to the Scheduler using the
update_resource_stats() method previously given and by adding the
instance_claim and resize_claim methods to the ComputeNode object
itself, so that a select_destinations() call from the conductor
could issue a call to each ComputeNode it elects for making sure it
would have enough resources for it.<br>
The current RT claims would be kept for backwards compatibility
purpose and doublechecking until we consider the new workflow good
enough for removing these claims.<br>
<br>
The above strategy is coming from a braindump but estimated as the
lowest common denominator for all the necessary changes. I'm really
concerned by any temptative of doing some big-bangs here which could
leave us to loose the focus on splitting the scheduler.<br>
<br>
<blockquote
cite="mid:6AF484C0160C61439DE06F17668F3BCB53398D79@ORSMSX114.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal">Feel free to correct this email but I
really want to make sure we all are in agreement on the same
thing so that we can actually get something done.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
Yeah, I assume that's quite frustrating because the design phase is
not yet ended. IMHO I think we need to find some sort of online
meetup for discussing all the bits of the split, as we can't wait
for the Kilo Summit to be here. The Gantt meetings are obviously not
the right place for discussing design and implementation so we need
to promote online tools for doing such work.<br>
<br>
We need ideas, we need volunteers, so feel free to raise your hand
(and your voice) if you reader, you're willing to work on that
effort.<br>
<br>
-Sylvain<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:6AF484C0160C61439DE06F17668F3BCB53398D79@ORSMSX114.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<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>