Add an admin-only API that allows setting VM resource quota at runtime
This blueprint is a supplement to Instance Resource Quota (https:/
- 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.
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:/
deferred from icehouse-3 to "next": http://
Removed from next, as next is now reserved for near misses from the last milestone --johnthetubagu
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:/
deferred from icehouse-3 to "next": http://
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)
