Open Stack

On Thu, Jun 5, 2014 at 12:19 AM, Mike Spreitzer <mspreitz at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140605/83121aeb/attachment.html>