c2ffc9150e
nova.compute and the hypervisor (i.e. libvirt). compute.node is no longer coupled tightly with libvirt. Instead, hypervisor connections are handled through a simple abstract interface. This has the additional advantage that there is no need to riddle the code with FLAGS.fake_libvirt checks, as we now have an interface behind which we can mock. The libvirt-specific code, and the fakevirt code used for unit tests, have moved into nova.virt. The fake_libvirt flag has been replaced with a connection_type flag, that will allow us to specify different connection types. The disk image handling (S3 or local disk image fetch) has moved into nova.virt.images, where it will be easier to share between connection types. The power_state values (Instance.RUNNING etc) and the INSTANCE_TYPES dictionary have moved into their own files (nova.compute.instance_types and nova.compute.power_state) so that we can share them without mutual dependencies between nova.compute.node and nova.virt.libvirt_conn.
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 compatability with the popular Amazon EC2 and S3 APIs. To monitor it from a distance: follow @novacc on twitter To tame it for use in your own cloud: read http://docs.novacc.org/getting.started.html To study its anatomy: read http://docs.novacc.org/architecture.html To disect it in detail: visit http://github.com/nova/cc To taunt it with its weaknesses: use http://github.com/nova/cc/issues To hack at it: read HACKING To watch it: http://test.novacc.org/waterfall