On 06/04/2014 12:19 PM, Mike Spreitzer wrote:
John Garbutt <j...@johngarbutt.com> wrote on 06/04/2014 04:29:36 AM:
> On 3 June 2014 14:29, Jay Pipes <jaypi...@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
