<tt><font size=2>John Garbutt <john@johngarbutt.com> wrote on 06/04/2014
04:29:36 AM:<br>
<br>
> On 3 June 2014 14:29, Jay Pipes <jaypipes@gmail.com> wrote:<br>
> > tl;dr<br>
> > =====<br>
> ><br>
> > Move CPU and RAM allocation ratio definition out of the Nova
scheduler and<br>
> > into the resource tracker. Remove the calculations for overcommit
out of the<br>
> > core_filter and ram_filter scheduler pieces.<br>
> ...<br>
> * If we have filters that adjust the ratio per flavour, we will still<br>
> need that calculation in the scheduler, but thats cool<br>
> <br>
> <br>
> In general, the approach I am advocating is:<br>
> * each host provides the data needed for the filter / weightier<br>
> * ideally in a way that requires minimal processing<br>
> <br>
> And after some IRC discussions with Dan Smith, he pointed out that
we<br>
> need to think about:<br>
> * with data versioned in a way that supports live-upgrades<br>
</font></tt>
<br><tt><font size=2>Not only live upgrades but also dynamic reconfiguration.</font></tt>
<br>
<br><tt><font size=2>Overcommitting affects the quality of service delivered
to the cloud user.  In this situation in particular, as in many situations
in general, I think we want to enable the service provider to offer multiple
qualities of service.  That is, enable the cloud provider to offer
a selectable level of overcommit.  A given instance would be placed
in a pool that is dedicated to the relevant level of overcommit (or, possibly,
a better pool if the selected one is currently full).  Ideally the
pool sizes would be dynamic.  That's the dynamic reconfiguration I
mentioned preparing for.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>
<br>
<br>