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. Regards, Mike
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
