Does not allow booting without a ramdisk

This needs two things addressed:

a) We need to support it in the virt drivers. Currently, we always pass a ramdisk to kvm, this needs to be conditional.
b) We have a concept of a default ramdisk. If none is set (either specifically in the RunInstances call or by way of a default setting in the machine image's metadata), there's a default value that will be used. We need to stop doing that.

I'm a little concerned about the scope of this change. In my opinion it would be perfectly acceptable for Austin to require a ramdisk.

Why should we do this pre-Austin?

The raw-disk-images patch already deals with not having a kernel & ramdisk:
https://code.launchpad.net/~justin-fathomdb/nova/raw-disk-images/+merge/38458

That was (re)submitted a few hours before feature-freeze, but hasn't been reviewed/merged.

The raw-disk-images patch assumes that no kernel <=> no ramdisk, but this would be easy to change so that you can have a kernel but no ramdisk.

For EC2 API compatibility reasons, instead of dropping the default, it uses a 'magic' ramdisk / kernel id. I think it's aki-00000000 and ari-00000000. As I recall, vish and I came up with this 'hack'.

Because the user must explicitly select the 'null' kernel/ramdisk, this avoids breaking anything.

I appreciate the effort to avoid breaking things, but I'm not sure what exactly has the potential for breaking?

Increasing importance, as this is blocking usage of official Ubuntu cloud images, which a lot of people are trying to run.

This is perhaps a naive comment, and likely will not be a popular one due to my mention of the evil that lurks in a town called Redmond.

It seems to me that this is necessary to deploy Windows images. Is this correct? If so, I think this is a big problem. I am trying to bring up a production cloud, and in the "real world" of business the inability to run a Windows image feels like a deal breaker. I wish everyone would choose to run Linux servers, but that is not going to happen.

Earlier today I proposed a branch that fixes this bug. It allows booting both whole-disk-images (i.e. relying on a boot loader in the disk image) as well as ramdisk-less booting (i.e. with an out-of-image kernel, but no ramdisk). It should land shortly.

Confirmed fixed, I could run an Ubuntu 10.10 cloud image with bzr487.