Open Stack

Yes, we refer to that blueprint in our design. I think the ultimate goal 
is the same -- providing a more fine-grained QoS control over resources in 
Nova (reservation/quota/etc, cpu/network/etc). Our blueprint is more 
focused/modest (addressing only cpu reservation), and a bit more generic 
(attempts to surface a bit higher-level abstraction, applicable also to 
platforms other than KVM).

Regards,
Alex

--
Alex Glikson
IBM research




From:   heut2008 <heut2008 at gmail.com>
To:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>, 
Date:   14/01/2013 08:45 AM
Subject:        Re: [openstack-dev] CPU reservation/entitlement in Nova



There is already a similar blueprint about limit instance resource usage 
https://blueprints.launchpad.net/nova/+spec/quota-instance-resource

my option is expose the cpu_share and cpu_period to user ,so it can be 
more flexable to implement variable policy.
this BP contains cpu and block IO usage control through cgroup and 
 bandwidth control through traffic control.


2013/1/14 Alex Glikson <GLIKSON at il.ibm.com>
Dear all, 

We have started working on implementation of CPU reservation/entitlement 
mechanism in Nova (
https://blueprints.launchpad.net/nova/+spec/cpu-entitlement). 
The idea is to allow associating explicit CPU allocation guarantees, in a 
more flexible way than it is done today in CoreFilter -- the user/admin 
will be able to define different CPU allocation guarantees for different 
instances. The approach we are taking is to use extra_specs of instance 
types to indicate the desired level of CPU allocation guarantees per vCPU 
(e.g., low=25% of a physical CPU, normal=50%, high=100%), which would 
apply to all instances created from the corresponding type. This fits 
nicely the resource model of most of the hypervisors, which have support 
for CPU guarantees built-in. For KVM, we are implementing the allocation 
guarantees using cpu shares in cgroups (by controlling the cpu shares of 
each instance and the total amount of shares allocated on a host). You can 
find more details in the wiki page linked from the blueprint. 

Would appreciate thoughts whether the approach we are taking makes sense, 
or any other feedback. 

Thanks! 
Alex 


--
Alex Glikson
IBM Research 

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Yaguang Tang _______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130114/7400b7e0/attachment.html>