1c8ad4553b
This patch adds the remainder of the recommended fixes
from the original bug report:
* Modifies methods in the compute manager that relied on
the DB power state to be in sync with the virt driver to
instead just query the power state of the instance from the
virt driver. This enables us to set the periodic tick to 10
for the problematic compute.manager.Manager._sync_power_states()
method.
* Modifies the _sync_power_states method in the following ways:
** Replace the call to driver.list_instances_detail() to a new,
driver-overrideable get_num_instances() call
** For each instance known by the database, call driver.get_info()
separately inside the loop instead of calling the expensive
list_instances_detail() method that can take a very long time
to complete on hosts with lots of instances
** Call greenthread.sleep(0) before each call to update the
database power state, enabling other periodic tasks to do work
Once again, I left an inefficient default implementation of the
new driver.get_num_instances() method in the base driver class. I
need help from folks who understand the Xen/VMWare drivers to do
an override for get_num_instances() in those drivers that calls
the underlying XenAPI or VMWare API.
Change-Id: I88002689cdda32124423da320f8c542e286be51b
The Choose Your Own Adventure README for Nova
You have come across a cloud computing fabric controller. It has identified itself as "Nova." It is apparent that it maintains compatibility with the popular Amazon EC2 and S3 APIs.
To monitor it from a distance: follow @openstack on twitter.
To tame it for use in your own cloud: read http://docs.openstack.org
To study its anatomy: read http://nova.openstack.org
To dissect it in detail: visit http://github.com/openstack/nova
To taunt it with its weaknesses: use http://bugs.launchpad.net/nova
To watch it: http://jenkins.openstack.org
To hack at it: read HACKING
To cry over its pylint problems: http://jenkins.openstack.org/job/nova-pylint/violations