On Thu, Jun 5, 2014 at 12:19 AM, Mike Spreitzer <mspre...@us.ibm.com> wrote:
> > 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. > > +1 I do agree that we need a dynamic overcommit setting per compute node. Or, maybe we also need pluggable resource calculation method for resource tracker. Since each compute node may have different hypervisor, hardware or quality-of-service commitment, it does not make sense to have unified settings in scheduler or resource tracker. The way preferred by I is: 1) Make our default cpu/ram filter simpler. No need to care about any overcommit ratio. Users can change the filter, if they hope that. 2) Resource tracker of each compute node can do the calculation according to its settings (or its calculation method, if it is pluggable), so that resource usage behavior can be specified to meet the unique requirement. -- Qin Zhao
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
