<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="GENERATOR" content="MSHTML 8.00.6001.23520">
</head>
<body>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">Mike,</font></span></div>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">interesting document.</font></span></div>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">What would be your approach to regions/zones/ensembles - does holistic mean to schedule w.r.t. I-specific constraints across _all_ hosts?</font></span></div>
<div dir="ltr" align="left"><span class="272054611-18092013">
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
</span>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">According to your naming and description, on the one hand I understand that the infrastructure orchestrator would not do any of the colocate-like constraint-evaluation.
 On the other hand, the holistic scheduler would leave some freedom in host selection up to the infras-scheduler, because it should try to align real state with the target state through tracking of the observed state?
</font></span><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">Do you split placement across the two (e.g. holistic decides on zone, infrastructure decides on host)?</font></span></div>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="272054611-18092013">
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">It seems both the holistic scheduler as well as the infrastructure orchestrator use the observed state, but wouldn't they consume different information
 (I mean not-overlapping)? What kind of information are shared / both used by the scheduler and orchestrator?</font></span></div>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">As you mention Boris' take on reducing scheduling efficiency, his perspective is direct notification and circumvent the DB. Effectively, this would also affect
 the synchronized state among scheduler instances. What's your take on this? </font>
</span>My humble understanding is that your holistic scheduling design (zoom in <a href="https://docs.google.com/drawings/d/1o2AcxO-qe2o1CE_g60v769hx9VNUvkUSaHBQITRl_8E/edit?pli=1">
https://docs.google.com/drawings/d/1o2AcxO-qe2o1CE_g60v769hx9VNUvkUSaHBQITRl_8E/edit?pli=1</a>) resembles a little bit the current nova
</font></span><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">DB approach with one central observed state (currently kept in the nova DB) and a synchronized/synthezised effective state in the scheduler instance (like the compute_node_get_all()
 call), however, why the separation between the holistic scheduler and infrastructure orchestrator? Once the scheduling decision is taken based on the effective state, the result could be given to the next level - why the orchestration? Multiple regions/service
 endpoints?</font></span></div>
</div>
<div dir="ltr" align="left"><span class="272054611-18092013"></span><font color="#0000ff" size="2" face="Arial"></font><font color="#0000ff" size="2" face="Arial"></font><font color="#0000ff" size="2" face="Arial"></font><font color="#0000ff" size="2" face="Arial"></font></span><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
</div>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">In case the holistic scheduler's "target state" decision that was taken on effective-state is a target that can't be achieved by recurring infrastructure
 orchestration: </font></span><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">When would you then requeue the I-CFN and re-evaluate the holistic scheduler's
 decision based on an updated effective-state? When do you decide the target state can't be met with the decisions of the holistic scheduler?</font></span></div>
</font></span>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="272054611-18092013">
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">I somehow would expect a "first come first served" policy from a provider. Is there some point of serialization of I-CFN deployments through one instance
 of a holistic scheduler or do you plan to have multiple instances of it? </font>
</span></span><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">When parallel holistic schedulers pass decisions to parallel orchestrated deployment, the pursuit of a complex application topology/pattern/template's target state may
 be repeatedly interrupted by other decisions/pursuits of smaller applications coming in, causing the complex deployment to be delayed. Where would you prevent that?</font></span></div>
</div>
<div dir="ltr" align="left"><span class="272054611-18092013"></span><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">Best, Manuel</font></span></div>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial"></font></span> </div>
<div dir="ltr" align="left"><span class="272054611-18092013"><font color="#0000ff" size="2" face="Arial">PS: though I'm neither developer, sub-group or board member yet, I very much welcome the idea of the deployment phases (S-CFN, I-CFN, CFN) and referencing
 levels as we had exactly that approach in a EU research project (IRMOS) applying ontologies and interlinking RDF entities. But we had made heavy use of asynchronous chained transactions in order to request/reserve/book resources which is heavy on the transaction
 state side and doesn't fit with RESTful req/res and eventual consistency. I believe the key observation in your suggestion however is IMHO to call for a somewhat clearer separation of Software policy, Infrastructure policy and the actually demanded virtual
 infrastructure.</font></span></div>
</div>
<br>
<blockquote style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
<div dir="ltr" lang="en-us" class="OutlookMessageHeader" align="left">
<hr tabindex="-1">
<font size="2" face="Tahoma"><b>From:</b> Mike Spreitzer [mailto:mspreitz@us.ibm.com]
<br>
<b>Sent:</b> Dienstag, 17. September 2013 07:00<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] [heat] [scheduler] Bringing things together for Icehouse<br>
</font><br>
</div>
<div></div>
<font size="2" face="sans-serif">I have written a brief document, with pictures.  See
</font><a href="https://docs.google.com/document/d/1hQQGHId-z1A5LOipnBXFhsU3VAMQdSe-UXvL4VPY4ps"><font size="2" face="sans-serif">https://docs.google.com/document/d/1hQQGHId-z1A5LOipnBXFhsU3VAMQdSe-UXvL4VPY4ps</font></a>
<br>
<br>
<font size="2" face="sans-serif">Regards,</font> <br>
<font size="2" face="sans-serif">Mike</font></blockquote>
</body>
</html>