0e7e3b2c18
This implements a [hosts] <=> [images] mapping in the simple scheduler that partitions your host resources into the part that services a particular image set, and the general cloud. This is useful, for example, if you want to specify a set of hosts to run utility VMs (cloudpipe, bastion, etc) that you don't want consuming resources from your generally available pool. When specifying a host with --isolated_hosts flags (comma-separated list) those hosts will only run the images specified in --isolated_images, and will not run any other images. The isolated images will not run on any other hosts. You can specify --skip_isolated_core_check to allow overcommitting of the isolated hosts. This allows utility vms that are not cpu bound to avoid the resource cheks the scheduler usually performs (based off of --max_cores). Change-Id: Ib2db5a605cb7560a169af9ff2a6dadb649da9c1d
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