<tt><font size=2>Mike Spreitzer <mspreitz@us.ibm.com> wrote on 30/10/2013
06:11:04 AM:<br>
> Date: 30/10/2013 06:12 AM</font></tt>
<br><tt><font size=2>> <br>
> Alex also wrote: <br>
> ``I wonder whether it is possible to find an approach that takes <br>
> into account cross-resource placement considerations (VM-to-VM <br>
> communicating over the application network, or VM-to-volume <br>
> communicating over storage network), but does not require delivering<br>
> all the intimate details of the entire environment to a single place<br>
> -- which probably can not be either of Nova/Cinder/Neutron/etc.. but<br>
> can we still use the individual schedulers in each of them with <br>
> partial view of the environment to drive a placement decision which
<br>
> is consistently better than random?'' <br>
> <br>
> I think you could create a cross-scheduler protocol that would <br>
> accomplish joint placement decision making --- but would not want
<br>
> to.  It would involve a lot of communication, and the subject
matter<br>
> of that communication would be most of what you need in a <br>
> centralized placement solver anyway.  You do not need "all
the <br>
> intimate details", just the bits that are essential to making
the <br>
> placement decision. </font></tt>
<br>
<br><tt><font size=2>Amount of communication depends on the protocol, and
what exactly needs to be shared.. Maybe there is a range of options here
that we can potentially explore, between what exists today (Heat talking
to each of the components, retrieving local information about availability
zones, flavors and volume types, existing resources, etc, and communicates
back with scheduler hints), and having a centralized DB that keeps the
entire data model.</font></tt>
<br><tt><font size=2>Also, maybe different points on the continuum between
'share few' and 'share a lot' would be a good match for different kinds
of environments and different kinds of workload mix (for example, as you
pointed out, in an environment with flat network and centralized storage,
the sharing can be rather minimal).</font></tt>
<br><tt><font size=2><br>
> Alex Glikson asked why not go directly to holistic if there is no
<br>
> value in doing Nova-only.  Yathi replied to that concern, and
let me<br>
> add some notes.  I think there *are* scenarios in which doing
Nova-<br>
> only joint policy-based scheduling is advantageous.</font></tt>
<br>
<br><tt><font size=2>Great, I am not trying to claim that such scenarios
do not exist - I am just saying that it is important to spell them out,
to better understand the trade-off between the benefit and the complexity,
and to make sure out design is flexible enough to accommodate the high-priority
ones, and extensible enough to accommodate the rest going forward.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Alex</font></tt>
<br>