Open Stack

Hi Jay,

The Congress project aims to handle something similar to your use cases.  I just sent a note to the ML with a Congress status update with the tag [Congress].  It includes links to our design docs.  Let me know if you have trouble finding it or want to follow up.

Tim

----- Original Message -----
| From: "Sylvain Bauza" <sylvain.bauza at gmail.com>
| To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
| Sent: Tuesday, February 25, 2014 3:58:07 PM
| Subject: Re: [openstack-dev] [OpenStack][Runtime Policy] A proposal for OpenStack run time policy to manage
| compute/storage resource
| 
| 
| 
| Hi Jay,
| 
| 
| Currently, the Nova scheduler only acts upon user request (either
| live migration or boot an instance). IMHO, that's something Gantt
| should scope later on (or at least there could be some space within
| the Scheduler) so that Scheduler would be responsible for managing
| resources on a dynamic way.
| 
| 
| I'm thinking of the Pets vs. Cattles analogy, and I definitely think
| that Compute resources could be treated like Pets, provided the
| Scheduler does a move.
| 
| 
| -Sylvain
| 
| 
| 
| 2014-02-26 0:40 GMT+01:00 Jay Lau < jay.lau.513 at gmail.com > :
| 
| 
| 
| 
| Greetings,
| 
| 
| Here I want to bring up an old topic here and want to get some input
| from you experts.
| 
| 
| Currently in nova and cinder, we only have some initial placement
| polices to help customer deploy VM instance or create volume storage
| to a specified host, but after the VM or the volume was created,
| there was no policy to monitor the hypervisors or the storage
| servers to take some actions in the following case:
| 
| 
| 1) Load Balance Policy: If the load of one server is too heavy, then
| probably we need to migrate some VMs from high load servers to some
| idle servers automatically to make sure the system resource usage
| can be balanced.
| 
| 2) HA Policy: If one server get down for some hardware failure or
| whatever reasons, there is no policy to make sure the VMs can be
| evacuated or live migrated (Make sure migrate the VM before server
| goes down) to other available servers to make sure customer
| applications will not be affect too much.
| 
| 3) Energy Saving Policy: If a single host load is lower than
| configured threshold, then low down the frequency of the CPU to save
| energy; otherwise, increase the CPU frequency. If the average load
| is lower than configured threshold, then shutdown some hypervisors
| to save energy; otherwise, power on some hypervisors to load
| balance. Before power off a hypervisor host, the energy policy need
| to live migrate all VMs on the hypervisor to other available
| hypervisors; After Power on a hypervisor host, the Load Balance
| Policy will help live migrate some VMs to the new powered
| hypervisor.
| 
| 4) Customized Policy: Customer can also define some customized
| policies based on their specified requirement.
| 
| 5) Some run-time policies for block storage or even network.
| 
| 
| 
| I borrow the idea from VMWare DRS (Thanks VMWare DRS), and there
| indeed many customers want such features.
| 
| 
| 
| I have filed a bp here [1] long ago, but after some discussion with
| Russell, we think that this should not belong to nova but other
| projects. Till now, I did not find a good place where we can put
| this in, can any of you show some comments?
| 
| 
| 
| [1]
| https://blueprints.launchpad.net/nova/+spec/resource-optimization-service
| 
| --
| 
| 
| Thanks,
| 
| Jay
| 
| _______________________________________________
| OpenStack-dev mailing list
| OpenStack-dev at lists.openstack.org
| http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
| 
| 
| 
| _______________________________________________
| OpenStack-dev mailing list
| OpenStack-dev at lists.openstack.org
| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=XDB3hT4WE2iDrNVK0sQ8qKooX2r1T4E%2BVHek3GREhnE%3D%0A&s=e2346cd017c9d8108c12a101892492e2ac75953e4a5ea5c17394c775cf086d7f
|