<font size=2 face="sans-serif">Mike, exactly: we would like to allow flexibility
& complexity at the Advisor level without it affecting the placement
computation.</font>
<br><font size=2 face="sans-serif">Advisors are expected to manifest complex
behavior as suggested by these BPs and gather constraints from multiple
sources (users and providers).</font>
<br>
<br><font size=2 face="sans-serif">The idea is indeed to define a protocol
that can express placement requests without exposing the engine to complex/high-level/rapidly-changing/3rd-party
semantics.</font>
<br><font size=2 face="sans-serif">I think BPs such as the group API and
</font><a href="https://blueprints.launchpad.net/nova/+spec/flexible-evacuate-scheduler"><font size=2 color=blue face="sans-serif">flexible-evacuation</font></a><font size=2 face="sans-serif">
combined with the power of LP solvers Yathiraj mentioned do push the scheduler
towards being a more generic placement oracle, so the protocol should probably
not be limited to the current "deploy one or more instances of the
same kind" request.</font>
<br>
<br><font size=2 face="sans-serif">Here's a more detailed description of
our thoughts on how such a protocol might look:</font>
<br><a href=https://wiki.openstack.org/wiki/Nova/PlacementAdvisorAndEngine><font size=2 color=blue face="sans-serif">https://wiki.openstack.org/wiki/Nova/PlacementAdvisorAndEngine</font></a>
<br><font size=2 face="sans-serif">We've concentrated on the Nova scheduler;
Would be interesting to see if this protocol aligns with Yathiraj's thoughts
on a global scheduler addressing compute+storage+network.</font>
<br><font size=2 face="sans-serif">Feedback is most welcome.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Gil</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Mike Spreitzer <mspreitz@us.ibm.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"OpenStack Development
Mailing List \(not for usage questions\)" <openstack-dev@lists.openstack.org>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">02/04/2014 10:10 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[Nova][Scheduler] Policy Based Scheduler and Solver Scheduler</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>> From: Khanh-Toan Tran <khanh-toan.tran@cloudwatt.com></font></tt><font size=3>
</font><tt><font size=2><br>
...<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 color=blue><u>https://docs.google.com/document/d/1RfP7jRsw1mXMjd7in72ARjK0fTrsQv1bqolOri</u></font></tt></a><tt><font size=2><br>
> IQB2Y</font></tt><font size=3><br>
</font><tt><font size=2><br>
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><font size=3>
<br>
</font><tt><font size=2><br>
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><font size=3> <br>
<br>
</font><tt><font size=2><br>
> From: Gil Rapaport <GILR@il.ibm.com></font></tt><font size=3>
</font><tt><font size=2><br>
...<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><font size=3><br>
</font><tt><font size=2><br>
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><font size=3> <br>
<br>
</font><tt><font size=2><br>
> 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><font size=3><br>
</font><tt><font size=2><br>
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><font size=3> <br>
<br>
</font><tt><font size=2><br>
> From: "Yathiraj Udupi (yudupi)" <yudupi@cisco.com></font></tt><font size=3>
</font><tt><font size=2><br>
...<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><font size=3>
</font><tt><font size=2><br>
<br>
I'll remind the other readers of our draft of such a thing, at</font></tt><font size=3>
<br>
</font><font size=3 color=blue><u><br>
</u></font><a href="https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA"><tt><font size=2 color=blue><u>https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA</u></font></tt></a><font size=3>
<br>
</font><tt><font size=2><br>
(you will have to re-assemble the URL if the ML software broke it for you)</font></tt><font size=3>
<br>
</font><tt><font size=2><br>
My take-aways from the Icehouse summit's review of that are as follows.</font></tt><font size=3>
<br>
</font><tt><font size=2><br>
(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><font size=3>
<br>
</font><tt><font size=2><br>
(2) The community was not convinced that this would scale as needed.</font></tt><font size=3>
<br>
</font><tt><font size=2><br>
(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><font size=3>
<br>
<br>
</font><tt><font size=2><br>
Regards,</font></tt><font size=3> </font><tt><font size=2><br>
Mike</font></tt><font size=3> </font><tt><font size=2>_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>