Add an admin-only API that allows setting VM resource quota at runtime

Registered by Yu Zhang on 2013-09-18

This blueprint is a supplement to Instance Resource Quota (https://blueprints.launchpad.net/nova/+spec/quota-instance-resource) supported by OpenStack from Grizzly. Instance Resource Quota is a static mechanism for cloud tenants to require precisely quantitative resources, while this new blueprint helps an administrator to effectively manage and utilize the cloud hardware resouces. In detail, this blueprint enables an admin to change physical resource allocation, CPU execution time, physical memory occupation, disk I/O bandwidth and priority, after VM instances have been created and in running. The benefits could be as the following:
    - The admin can use this runtime mechanism to change physical resource allocation, if a tenant over-claims resource quota when creating instances. But the instances themselves do not need to be terminated and re-created while resources changed;
    - The admin can also use this runtime mechanism to dynamically adjust resource quota of instances during running according to the change of instance workloads and/or priorities.

Parts of this blueprint related with VCPU performance management have been implemented in our local OpenStack Grizzly deployment and work well.

Blueprint information

Status:
Started
Approver:
None
Priority:
Undefined
Drafter:
Yu Zhang
Direction:
Needs approval
Assignee:
Yu Zhang
Definition:
Drafting
Series goal:
None
Implementation:
Started
Milestone target:
None
Started by
Yu Zhang on 2013-10-29

Related branches

Sprints

Whiteboard

Deferred to icehouse-3 as the blueprint was not approved by the icehouse-2 blueprint approval deadline. --russellb

My gut feeling is that this doesn't feel very "cloudy". However, this is for control knobs that already exist via flavor extra specs. The extra ability to modify them on the fly seems like a logical extension to that. --russellb

So I didn't know we had a static mechanism for this in the first place. Before approving this BP I would like to see two things:
* Make this feature more visible, I am not sure exactly how to do this, but its hidden away and is very hard to find today
* Add tempest tests for this, going with the 'if its not tested, its broken' mantra the initial BP is not tested and therefore is broken. So lets get tests in place for the static version of this first.
 --jogo

Russell, I agree, this feels uncloudy to me. I'd rather not have this in Nova. --dansmith

Russell, jogo and Dan, Thank you so much for your comments! Your help and inputs are highly appreciated to improve my thoughts :)
    The key difference between this blueprint and the flavor-based solution (in Grizzly) is, what we will control: A flavor? Or a created and running instance (even a group of instances)?
    If we use the existing flavor-based solution, we can create a flavor with some extra specs about physical resource allocation. The physical resources used by an instance are decided and allocated when defining and creating the instance using that flavor. The resources can not be changed during instance running, if no other feature in Nova is provided. Even if we can change the flavor on-the-fly, the instances created using this flavor will not be influenced anymore.
    However, according to user cases, Admins have the requirements to adjust physical resource allocation according to workloads to improve resource utilization. Such requirements are hard to be matched via the flavor-based feature, since it does not influence running instances. The Admins need some other solutions to dynamically adjust resources occupied by instances on-the-fly.
    Therefore, my blueprint and the existed flavor-based feature are designed for
different cases and scenarios. My purpose is to adjust the physical resources of a running instance, but not a flavor. -- YuZhang

Jogo, in fact I knew that static mechanism (https://blueprints.launchpad.net/nova/+spec/quota-instance-resource) when I planned to submit this BP and took some survey efforts. I firstly found that in the Release Notes of Grizzly, then I read its implementation in Nova code base, which is totally based on cgroup and seems reasonable. I did not test it, therefore can not provide more concrete info to you. Sorry for that! -- YuZhang

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguyDeferred to icehouse-3 as the blueprint was not approved by the icehouse-2 blueprint approval deadline. --russellb

My gut feeling is that this doesn't feel very "cloudy". However, this is for control knobs that already exist via flavor extra specs. The extra ability to modify them on the fly seems like a logical extension to that. --russellb

So I didn't know we had a static mechanism for this in the first place. Before approving this BP I would like to see two things:
* Make this feature more visible, I am not sure exactly how to do this, but its hidden away and is very hard to find today
* Add tempest tests for this, going with the 'if its not tested, its broken' mantra the initial BP is not tested and therefore is broken. So lets get tests in place for the static version of this first.
 --jogo

Russell, I agree, this feels uncloudy to me. I'd rather not have this in Nova. --dansmith

Russell, jogo and Dan, Thank you so much for your comments! Your help and inputs are highly appreciated to improve my thoughts :)
    The key difference between this blueprint and the flavor-based solution (in Grizzly) is, what we will control: A flavor? Or a created and running instance (even a group of instances)?
    If we use the existing flavor-based solution, we can create a flavor with some extra specs about physical resource allocation. The physical resources used by an instance are decided and allocated when defining and creating the instance using that flavor. The resources can not be changed during instance running, if no other feature in Nova is provided. Even if we can change the flavor on-the-fly, the instances created using this flavor will not be influenced anymore.
    However, according to user cases, Admins have the requirements to adjust physical resource allocation according to workloads to improve resource utilization. Such requirements are hard to be matched via the flavor-based feature, since it does not influence running instances. The Admins need some other solutions to dynamically adjust resources occupied by instances on-the-fly.
    Therefore, my blueprint and the existed flavor-based feature are designed for
different cases and scenarios. My purpose is to adjust the physical resources of a running instance, but not a flavor. -- YuZhang

Jogo, in fact I knew that static mechanism (https://blueprints.launchpad.net/nova/+spec/quota-instance-resource) when I planned to submit this BP and took some survey efforts. I firstly found that in the Release Notes of Grizzly, then I read its implementation in Nova code base, which is totally based on cgroup and seems reasonable. I did not test it, therefore can not provide more concrete info to you. Sorry for that! -- YuZhang

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguy

Marking this blueprint as definition: Drafting. If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.