Open Stack

On 06/04/2014 12:19 PM, Mike Spreitzer wrote:
> 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.

What you describe above is what the host aggregates functionality is 
for. Unfortunately, host aggregates are an API extension and so Nova 
can't rely on them as a general and reliable way of grouping host 
resources together.

All the more reason why adding integral things like host 
aggregates/groups as an extension was a mistake.

-jay