Open Stack

John Garbutt <john at johngarbutt.com> wrote on 06/04/2014 04:29:36 AM:

> On 3 June 2014 14:29, Jay Pipes <jaypipes at gmail.com> wrote:
> > tl;dr
> > =====
> >
> > Move CPU and RAM allocation ratio definition out of the Nova scheduler 
and
> > into the resource tracker. Remove the calculations for overcommit out 
of the
> > core_filter and ram_filter scheduler pieces.
> ...
> * If we have filters that adjust the ratio per flavour, we will still
> need that calculation in the scheduler, but thats cool
> 
> 
> In general, the approach I am advocating is:
> * each host provides the data needed for the filter / weightier
> * ideally in a way that requires minimal processing
> 
> And after some IRC discussions with Dan Smith, he pointed out that we
> need to think about:
> * with data versioned in a way that supports live-upgrades

Not only live upgrades but also dynamic reconfiguration.

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.

Regards,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140604/e11a9bbe/attachment.html>