<tt><font size=2>> From: Khanh-Toan Tran <khanh-toan.tran@cloudwatt.com></font></tt>
<br><tt><font size=2>...<br>
> There is an unexpected line break in the middle of the link, so I
post it<br>
> again:<br>
> <br>
> </font></tt><a href=https://docs.google.com/document/d/1RfP7jRsw1mXMjd7in72ARjK0fTrsQv1bqolOri><tt><font size=2>https://docs.google.com/document/d/1RfP7jRsw1mXMjd7in72ARjK0fTrsQv1bqolOri</font></tt></a><tt><font size=2><br>
> IQB2Y<br>
</font></tt>
<br><tt><font size=2>The mailing list software keeps inserting that line
break.  I re-constructed the URL and looked at the document.  As
you point out at the end, the way you attempt to formulate load balancing
as a linear objective does not work.  I think load-balancing is a
non-linear thing.</font></tt>
<br>
<br><tt><font size=2>I also doubt that simple load balancing is what cloud
providers want; I think cloud providers want to bunch up load, within limits,
for example to keep some hosts idle so that they can be powered down to
save on costs or left available for future exclusive use.</font></tt>
<br>
<br>
<br><tt><font size=2>> From: Gil Rapaport <GILR@il.ibm.com></font></tt>
<br><tt><font size=2>...<br>
> As Alex Glikson hinted a couple of weekly meetings ago, our approach<br>
> to this is to think of the driver's work as split between two entities:
<br>
> -- A Placement Advisor, that constructs placement problems for <br>
> scheduling requests (filter-scheduler and policy-based-scheduler)
<br>
> -- A Placement Engine, that solves placement problems (HostManager
<br>
> in get_filtered_hosts() and solver-scheduler with its LP engine).
</font></tt>
<br>
<br><tt><font size=2>Yes, I see the virtue in that separation.  Let
me egg it on a little.  What Alex and KTT want is more structure in
the Placement Advisor, where there is a multiplicity of plugins, each bound
to some fraction of the whole system, and a protocol for combining the
advice from the plugins.  I would also like to remind you of another
kind of structure: some of the placement desiderata come from the cloud
users, and some from the cloud provider.</font></tt>
<br>
<br>
<br><tt><font size=2>> From: "Yathiraj Udupi (yudupi)" <yudupi@cisco.com><br>
...<br>
> Like you point out, I do agree the two entities of placement <br>
> advisor, and the placement engine, but I think there should be a <br>
> third one – the provisioning engine, which should be responsible
for<br>
> whatever it takes to finally create the instances, after the <br>
> placement decision has been taken. </font></tt>
<br>
<br><tt><font size=2>I'm not sure what you mean by "whatever it takes
to finally create the instances", but that sounds like what I had
assumed everybody meant by "orchestration" (until I heard that
there is no widespread agreement) --- and I think we need to take a properly
open approach to that.  I think the proper API for cross-service whole-pattern
scheduling should primarily focus on conveying the placement problem to
the thing that will make the joint decision.  After the joint decision
is made comes the time to create the individual resources.  I think
we can NOT mandate one particular agent or language for that.  We
will have to allow general clients to make calls on Nova, Cinder, etc.
to do the individual resource creations (with some sort of reference to
the decision that was already made).  My original position was that
we could use Heat for this, but I think we have gotten push-back saying
it is NOT OK to *require* that.  For example, note that some people
do not want to use Heat at all, they prefer to make individual calls on
Nova, Cinder, etc.  Of course, we definitely want to support, among
others, the people who *do* use Heat.</font></tt>
<br>
<br>
<br><tt><font size=2>> From: "Yathiraj Udupi (yudupi)" <yudupi@cisco.com></font></tt>
<br><tt><font size=2>...<br>
> The solver-scheduler is designed to solve for an arbitrary list of
<br>
> instances of different flavors. We need to have some updated apis
in<br>
> the scheduler to be able to pass on such requests. Instance group
<br>
> api is an initial effort to specify such groups.</font></tt>
<br><tt><font size=2><br>
I'll remind the other readers of our draft of such a thing, at</font></tt>
<br>
<br><a href="https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA"><tt><font size=2>https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA</font></tt></a>
<br>
<br><tt><font size=2>(you will have to re-assemble the URL if the ML software
broke it for you)</font></tt>
<br>
<br><tt><font size=2>My take-aways from the Icehouse summit's review of
that are as follows.</font></tt>
<br>
<br><tt><font size=2>(1) do NOT put orchestration under the covers (as
I said above), allow general clients to make the calls to create the individual
resources.</font></tt>
<br>
<br><tt><font size=2>(2) The community was not convinced that this would
scale as needed.</font></tt>
<br>
<br><tt><font size=2>(3) There were some remarks about "too complicated"
but I am not clear on whether the issue(s) were: (a) there was not clear/compelling
motivation for some of the expressiveness offered, (b) there is a simpler
way to accomplish the same things, (c) it's all good but more than we can
take on now, and/or (d) something else I did not get.</font></tt>
<br>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>